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



    \
     
     \ /
      Last update: 2009-02-25 09:33    [W:0.023 / U:1.280 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site