Re: [PATCH v2 1/3] kernel-shark: Reorder the priority when searching for trace-cmd libs

[Patrick McLean <chutzpah@gentoo.org>]

On Wed, 13 Mar 2019 15:06:02 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Wed, 13 Mar 2019 11:42:35 -0700
> Patrick McLean <chutzpah@gentoo.org> wrote:
> 
> > (especially when trace-cmd and trace-cmd are
> > separate packages)  
> 
> That should be a fun stunt. ;-)
> 
> But yeah, we are looking into separating KernelShark out of trace-cmd
> in the future, but depending on libftrace.so (the guts of trace-cmd)
> when that is ready. First we need to finish libtraceevent.so, which
> will live in the Linux kernel git repo under tools/lib/traceeevent.
> Would that be an issue in packaging libtraceevent?
> 

Oops, editing error ;).

That is likely not an issue for distros that pick a kernel and stick
with it, they would just package the one that ships with the kernel
that version chose (barring any breaks with stable releases). On
distros that track upstream kernels, that would be kind of a pain to
deal with, but potentially still manageable by packaging the library
with the kernel (potentially with some LD_LIBRARY_PATH magic).

On Gentoo it would be very difficult to deal with, since kernels are
built by users, but I suspect that is kind of a niche. In practice
there would probably be a package that uses the kernel source tree to
build a "system" version (that is what is currently done with perf,
though unfortunately it lags a bit behind kernel releases).

I would imagine kernel developers would have to come up with a way to
handle it themselves, since they would have user space packages that
depend on a library produced from their kernel source tree.

I assume it will have a fairly stable API/ABI, so one would not have to
worry about recompiling userspace tools when a kernel gets updated?