Messages in this thread | | | Date | Wed, 25 Feb 2009 00:28:52 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH 2/4] tracing: add event trace infrastructure |
| |
On Wed, 25 Feb 2009 09:11:18 +0100 Ingo Molnar <mingo@elte.hu> wrote:
> > * Andrew Morton <akpm@linux-foundation.org> wrote: > > > On Tue, 24 Feb 2009 23:08:56 -0500 (EST) Steven Rostedt <rostedt@goodmis.org> 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.
| |