Good fences make good projects? [LWN.net]

Good fences make good projects?

Posted Nov 10, 2011 17:49 UTC (Thu) by ccurtis (guest, #49713)
Parent article: Good fences make good projects?

I'm not sure I see much good in integrating non-kernel stuff into the kernel tree, but I wonder if it would make more sense if some of these tools were perceived as test tools comprising part of a kernel test suite.

Then, there would be a test tool that exercises some part of the ABI while the user-friendly tool is hosted somewhere else. The test tool could be developed in-tree until the ABI is declared stable, at which point it is forked into an external project while the original tool can be used as a reference implementation for other tool developers.

When that "stable" point is reached may be contentious, but it may also be straightforward. For instance, the first patch that says "Make tool <foo> easier for users to run..." could be a good indicator that it's ready to be forked out.

(Log in to post comments)

Good fences make good projects?

Posted Nov 11, 2011 9:19 UTC (Fri) by ebirdie (subscriber, #512) [Link]

>I'm not sure I see much good in integrating non-kernel stuff into the kernel tree, but I wonder if it would make more sense if some of these tools were perceived as test tools comprising part of a kernel test suite.

I think this is very interesting idea and replying & quoting this just to raise attention and some insightful consideration for it.

The article raised a question, why perf is deemed to indefinite life in the kernel tree? As I have considered perf to be a kernel performance tool for kernel developers and haven't yet seen the userspace tools I use to monitor and tune system performance to use perf for anything, I haven't payed much attention to it. Does perf's life in kernel tree and the perception hinder its worthyness and development of use in userspace? Thus a kernel test & ABI suite/tree like linux-next but to reverse direction seems logical from a sysadmin perspective.

Good fences make good projects?

Posted Nov 11, 2011 11:22 UTC (Fri) by jnareb (subscriber, #46500) [Link]

> The article raised a question, why perf is deemed to indefinite life in the kernel tree? As I have considered perf to be a kernel performance tool for kernel developers and haven't yet seen the userspace tools I use to monitor and tune system performance to use perf for anything, I haven't payed much attention to it. Does perf's life in kernel tree and the perception hinder its worthyness and development of use in userspace? Thus a kernel test & ABI suite/tree like linux-next but to reverse direction seems logical from a sysadmin perspective.

"perf" development in Linux kernel tree makes it hard to package it and use it outside of kernel profiling. I was trying to use it to profile application (with limited success), in addition to other profiling tools that use perf events via PAPI library, and it was a bit difficult to make it work.

Good fences make good projects?

Posted Nov 11, 2011 21:47 UTC (Fri) by bcopeland (subscriber, #51750) [Link]

> "perf" development in Linux kernel tree makes it hard to package it and use it outside of kernel profiling.

It seems the way it is handled in ubuntu at least is to package up perf as a script that just tells you to get yet another kernel-specific package that contains the actual binary. Given that, I find it amusing that perf is held as the gold standard for this kind of thing.