[lkml]   [2010]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] [PATCH 4/7] Uprobes Implementation
    Hi Peter, 

    > > >
    > >
    > > My reply in
    > >
    > > addresses this.
    > Right, so all that need be done is add the multiple probe stuff to UBP
    > and its a sane interface to use on its own, at which point I'd be
    > inclined to call that uprobes (UBP really is an crap name).

    I am fine with renaming ubp to a suggested name. The reason for splitting
    uprobes to two layers was to allow others (currently none) to reuse the
    current ubp layer. It was felt that there could be multiple clients for
    ubp who could co-exist.

    However ubp alone is not enough to provide the userspace tracing.
    Currently it wouldn't understand synchronization between different
    threads of a process, process life time issues, context in which the
    handler has to be run.

    As pointed out by Jim earlier, we have segregrated that layer which
    takes care of the above issues into the uprobes layer.

    For example, while inserting a breakpoint, one of the threads of a
    process could be running at the same place where we are trying to place
    a breakpoint. Or there could be two threads that could be racing to
    insert/delete a breakpoint. These synchronization issues are all handled
    by the Uprobes layer.

    Uprobes layer would need to be notified of process life-time events
    like fork/clone/exec/exit.
    It also needs to know
    - when a breakpoint is hit
    - stop and resume a thread.

    Uprobes layer uses utrace to be notified of the process life time events
    and the signal handling part.

    Thanks and Regards

    > Then we can ditch the whole utrace muck as I see no reason to want to
    > use that, whereas the ubp (given a sane name) looks interesting.

     \ /
      Last update: 2010-01-15 11:29    [from the cache]
    ©2003-2014 Jasper Spaans. hosted at Digital Ocean