On Tue, 29 Jul 2025 19:21:57 -0300 Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > > As this is an evolving mechanism, having the corresponding library in > > the kernel similar to what we do with perf and other things makes a lot > > of sense. > > If we did this everywhere we'd have hundreds of libraries in the > kernel tree and I would feel bad for all the distros that have to deal > with packaging such a thing :( > > It is great for development but I'm not sure mono-repo directions are > so good for the overall ecosystem. I have to agree here. When libtraceevent was in the kernel, it was a pain to orchestrate releases with distros. When it was moved out of the kernel, it made it much easier to manage. The main issue was versioning numbers. I know the kernel versioning is simply just "hey we added more stuff" and the numbers are meaningless. But a library usually has a different cycle than the kernel. If it doesn't have any changes from one kernel release to the next, the distros will make a new version anyway, as each kernel release means a new library release. This luoctl.c isn't even a library, as it has a "main()" and looks to me like an application. So my question is, why is it in tools/lib? -- Steve
