Re: [PATCH 2/4] tracing: add event trace infrastructure

[Andrew Morton]

On Wed, 25 Feb 2009 09:11:18 +0100 Ingo Molnar <mingo@xxxxxxx> wrote:

> 
> * Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> > On Tue, 24 Feb 2009 23:08:56 -0500 (EST) Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> > 
> > > > Gad, what a lot of stuff.
> > > > 
> > > > Use strncpy_from_user()?
> > > > 
> > > > Use strstrip()?
> > > > 
> > > > Why do we care about leading and trailing whitespace - user error!
> > > 
> > > This is because i want:
> > > 
> > >  cat available_events > set_event
> > > 
> > > to work.
> > 
> > :(
> > 
> > Why on earth do we keep on putting all these pretty-printers 
> > and pretty-parsers into the kernel?  I mean, how hard is it 
> > for userspace to read a text file, do some basic substitutions 
> > and print it out again?
> 
> Note that there's no mandatory user-space component here - the 
> final destination is the kernel developer's eyes in 90% of the 
> cases. These traces get pasted into email, etc. etc.
> 
> So leading spaces, meaningful formatting and general hands-on 
> usability is important. [ I know, it's a strange concept in the 
> kernel, we tend to have a perversion for the most unusable and 
> most inconsistent user interfaces ;-) ]
> 
> It's also a balancing act. We dont want to put all of TeX into 
> the kernel obviously. Nor do we want the default to be the 
> opposite end of the spectrum: to output raw binary records. So 
> we find some middle ground. That middle ground is inluenced by 
> the developers using this stuff.
> 

<For the enty enth pissing-in-the-wind time>

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'.

Probably it's already too late for ktrace though - that hole is already
dug.


Last time I pissed in this wind I got fobbed off with some stupid "put
it in util-linux" answer.  But of course we won't do that, because it's
MUCH harder and slower and more complex than just patching the kernel
tree.  So nothing happened.  Again.

And please let's not all sit here busily thinking up improbable reasons
why it can't possibly work.  We're clever!  We can do this sort of
thing!  If problems arise, we fix them!

The only extant example I can think of is getdelays.c, and that was a
totally half-assed effort with no infrastructural support at all.  But
quite a lot of people use it, and patches occasionally come in for it,
no problems.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/