Messages in this thread | | | Date | Wed, 25 Feb 2009 08:54:37 -0500 | From | Theodore Tso <> | Subject | Re: [PATCH 2/4] tracing: add event trace infrastructure |
| |
On Wed, Feb 25, 2009 at 12:28:52AM -0800, Andrew Morton wrote: > A better approach would be to design simple, robust kernel interfaces > which make sense and which aren't made all complex by putting the user > interface in kernel space. And to maintain corresponding userspace > tools which manipulate and present the IO from those kernel interfaces. > > But we don't do that, because userspace is hard, because we don't have > a delivery process. But nobody has even tried! We can do this - it > starts with `mkdir -p userspace/ktrace'.
I don't think it's just because we don't have a delivery process. I think it's because we've just been burned so many times with complex user space tools that are built in C++, have impossible-to-understand error handling ("try again with -vvvvvvv"), is hard to build because they have huge dependencies on external libraries, or is filled with distro dependencies and might not build on various distributions, or is dependent on the RPM macros, etc.
Sure, if we do it ourselves, maybe we won't fall into the same set of traps. But after so many years of failure in creating a simple, usable, tracing infrasructure, why not have something which is self-contained in the kernel? We can have a binary interface for the people who make the uber-complex userspace tools, but 99% of the time we don't need the complexity.
Also, I suspect the delivery problem is a lot more complicated than you make it out to be. It's not enough just to solve the kbuild issues; there are the distribution packaging issues as well, and to the extent that we have kernel-version-dependent userspace tools, how do we standardize a system so that when the 2.6.29-rc6-gc457db2 kernel is botted, we are using the tools associated with that kernel, and when we have the 2.6.28.2 kernel booted, we use those tools instead?
If someone wants to work on putting together that infrastructure, I'm sure it could be useful for more than just tracing. I'll note though that not all distributions have a reasonable system for dealing with kernel-version dependent firmware packages yet, either. (And whatever happened to packaging firmware as a separate package from the kernel; I haven't seen much progress on that front either.)
Sometimes, it's just much simpler and easier if we keep things all bundled together in the kernel image.
- Ted
| |