On Wed, 13 Mar 2019 15:06:02 -0400 Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > On Wed, 13 Mar 2019 11:42:35 -0700 > Patrick McLean <chutzpah@xxxxxxxxxx> 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?
|