[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231004174321.5afa2fb6@gandalf.local.home>
Date: Wed, 4 Oct 2023 17:43:21 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Alan Maguire <alan.maguire@...cle.com>
Cc: Jakub Kicinski <kuba@...nel.org>,
Johannes Berg <johannes@...solutions.net>,
linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
netdev@...r.kernel.org, linux-wireless@...r.kernel.org
Subject: Re: [PATCH 0/4] tracing: improve symbolic printing
On Wed, 4 Oct 2023 22:35:07 +0100
Alan Maguire <alan.maguire@...cle.com> wrote:
> One thing we've heard from some embedded folks [1] is that having
> kernel BTF loadable as a separate module (rather than embedded in
> vmlinux) would help, as there are size limits on vmlinux that they can
> workaround by having modules on a different partition. We're hoping
> to get that working soon. I was wondering if you see other issues around
> BTF adoption for embedded systems that we could put on the to-do list?
> Not necessarily for this particular use-case (since there are
> complications with trace data as you describe), but just trying to make
> sure we can remove barriers to BTF adoption where possible.
I wonder how easy is it to create subsets of BTF. For one thing, in the
future we want to be able to trace the arguments of all functions. That is,
tracing all functions at the same time (function tracer) and getting the
arguments within the trace.
This would only require information about functions and their arguments,
which would be very useful. Is BTF easy to break apart? That is, just
generate the information needed for function arguments?
Note, pretty much all functions do not pass structures by values, and this
would not need to know the contents of a pointer to a structure. This would
mean that structure layout information is not needed.
-- Steve
Powered by blists - more mailing lists