lkml.org 
[lkml]   [2002]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] LTT for 2.5.38 1/9: Core infrastructure

    OK, I think we've agreed on most of the issues already. Just a couple of
    details:

    Ingo Molnar wrote:
    > yes. And in fact i'd suggest to not make it a driver but create a new
    > kernel/trace.c file - if it's a central mechanism then it should live in a
    > central place.

    OK, will do. Need to add a syscall for controlling tracing though (currently
    done through device ioctl()).

    [...]
    Regarding callbacks:

    Will be removed.

    > are you sure you want to copy filenames? File descriptor and inode numbers
    > ought to be enough.

    We record the filename only once (i.e. upon exec or open). After that,
    the fd is used.

    > > - Synchronize with trace daemon to save trace data. (A single per-CPU
    > > circular buffer may be useful when doing kernel devleopment, but user
    > > tracing often requires N buffers).
    > >
    > > In addition, because this data is available from user-space, you need to
    > > be able to deal with many buffers. For example, you don't want some
    > > random user to know everything that's happening on the entire system for
    > > obvious security reasons. So the tracer will need to be able to have
    > > per-user and per-process buffers.
    >
    > in fact i have the feeling that you should not expose any of this to
    > ordinary users. Performance measurements are to be done by administrator
    > types - all this stuff has heavy memory allocation impact anyway.

    Sure, for performance measurements it's the admin, but per my earlier
    descriptions:
    - users who want to debug synchronization problems of their own tasks
    shouldn't see the kernel's behavior.
    - users who want to log custom events separate from the kernel events
    don't want to see the kernel's beavhior.

    In any case, what the admin sees and what the users see of the tracing
    facility will certainly be different (i.e. not the same level of
    flexibility).

    > in exactly which cases do you want to have multiple trace buffers? A
    > single (large enough if needed) buffer should be enough. This i think is
    > one of the core issues of your design.

    OK, we'll revisit this issue.

    Karim

    ===================================================
    Karim Yaghmour
    karim@opersys.com
    Embedded and Real-Time Linux Expert
    ===================================================
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:29    [W:0.025 / U:58.528 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site