lkml.org 
[lkml]   [2009]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2009-02-25 14:57    [W:0.124 / U:0.796 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site