From: Lv Ying <lvying6@huawei.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: <mchehab@kernel.org>, <linux-trace-users@vger.kernel.org>,
<linux-trace-devel@vger.kernel.org>,
"Fangxiuning (Jack, EulerOS)" <fangxiuning@huawei.com>
Subject: Re: How to solve the coupling between libtraceevent and kernel trace?
Date: Tue, 8 Aug 2023 10:36:16 +0800 [thread overview]
Message-ID: <03d598ef-864d-c6d7-2c6f-65744b32eb2d@huawei.com> (raw)
In-Reply-To: <20230807210937.3ece4d63@gandalf.local.home>
Hi Steven:
On 2023/8/8 9:09, Steven Rostedt wrote:
> On Sat, 5 Aug 2023 11:57:48 +0800
> Lv Ying<lvying6@huawei.com> wrote:
>
>> I find this kernel
>> patch(https://lore.kernel.org/all/477b362dba1ce7fab9889a1a8e885a62c472f041.1516069914.git.tom.zanussi@linux.intel.com/T/#u)
>> change TIME_STAMP to 8 bytes. Maybe this commit is the first time
>> RINGBUF_TYPE_TIME_STAMP is really implemented in the kernel.
> Yes, I know what caused the breakage.
>
>> When rasdaemon use old libtrace(12 byte version of TIME_STAMP) on newer
>> kernel(8 bytes version of RINGBUF_TYPE_TIME_STAMP). Libtrace takes too
>> long to parse timestamp events and appends the first 4 bytes of the next
>> trace event as the last 4 bytes of the timestamp event. Such wrong
>> parsing will lead to completely wrong parsing of the adjacent trace
>> event field. For example, in rasdaemon we have a situation like this,
>> libtrace parse devlink_health_report trace event next timestamp trace
>> event as block_rq_complete trace event, which will cause coredump in
>> block_rq_complete rasdaemon handler.
>>>> So if libtraceevent is released out of(independent) kernel, how does
>>>> libtraceevnt to keep compatible with the running kernel(maybe not the
>>>> newest)?
>>>>
>>> Now that it has been implemented, it's not going to change. 8 bytes is now
>>> an API. Any more updates should not cause a problem with libtraceevent as
>>> there's many more tools that depend on it working. And the fact that it is
>>> no longer in the kernel, guarantees more that the interface will remain
>>> stable.
>>>
>> I am worried similar libtraceevent-kernel compatibility problem. I think
>> it's a good way to sort out the interfaces that libtraceevent depends on
>> the kernel and add test cases to determine whether libtraceevent can run
>> on the current kernel, or to know which interfaces do not match.
>>
>>> rasdaemon should be using the external libtraceevent library because it
>>> will be able to get more information out of any new data. Newer kernels
>>> should not break existing libtracevent, but it may just skip over new
>>> features.
>>>
>>> -- Steve
>>>
>>> .
>>>
>> rasdaemon now use the external libtraceevent, but rasdaemon will be
>> shipped in many version OS by OSV, so how to ensure that rasdaemon runs
>> correctly on various kernel versions using external libtraceevent needs
>> to be considered.
>>
> The latest libtraceevent and libtracefs should work with all previous
> versions of the kernel. TIMESTAMP was not implemented in the kernel when
> kbuffer.c added it. That was my mistake and it will not happen again.
>
> trace-cmd uses the latest libtracevent and libtracefs, and it works on
> kernels back to 2.6.32 (when tracing was added). Using the latest
> libtraceevent will work on all older kernels.
>
> All should be good. What exactly are you worried about?
I didn't know much about kernel tracefs before, so I thought there was a
compatibility problem like timestamp. After your answer, I know that
timestamp is an exception. I can now happily use libtraceevent directly
on different versions of the kernel.
Thanks again for your answer :)
--
Thanks!
Lv Ying
prev parent reply other threads:[~2023-08-08 2:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-04 9:52 How to solve the coupling between libtraceevent and kernel trace? Lv Ying
2023-08-04 16:15 ` Steven Rostedt
2023-08-05 3:49 ` Lv Ying
2023-08-05 3:57 ` Lv Ying
2023-08-08 1:09 ` Steven Rostedt
2023-08-08 2:36 ` Lv Ying [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=03d598ef-864d-c6d7-2c6f-65744b32eb2d@huawei.com \
--to=lvying6@huawei.com \
--cc=fangxiuning@huawei.com \
--cc=linux-trace-devel@vger.kernel.org \
--cc=linux-trace-users@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).