lkml.org 
[lkml]   [2008]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/2] utrace
    On Tue, Aug 26, 2008 at 08:17:12PM -0400, Frank Ch. Eigler wrote:
    > Alexey Dobriyan <adobriyan@gmail.com> writes:
    >
    > > [...] And some internal details still horrible and overdesigned
    > > just like at the very beginning.
    >
    > Please point out specific areas, and I'm sure there will be a reasonable
    > explanation why they turned out this way.
    >
    > As for whether "struct utrace" should be a member of vs. pointed-to
    > from task_struct, it may come down to the perceived need to avoid
    > penalizing every thread with a hundred-odd bytes extra, whether or not
    > they are being utrace-controlled.

    Yes, that's your price for avoiding more races, more code, more races,
    more tricky code and ultimately more ways to fsckup.

    God, you're in the very tricky Unix subsystem only a few people know
    intimately, and what we see? utrace code is just as tricky.

    When you're confident that interaction with engines part is fine, all
    stupid bugs were fixed, go change struct utrace to pointer. Now it can
    very well be a lie to say less memory is used because slab allocator
    rounds up sizes to certain degree.

    > > [...] Linked list of attached tracers? I don't know. One the bad
    > > side, where are those nice tracing modules? Where are they?
    >
    > Among others, utrace is an enablement layer for systemtap user-space
    > probing, through another subsequent part that implements a
    > kprobes-like API for user-space tasks. All this code now exists in at
    > least prototype form, so if you need to see the bigger picture, look
    > that way. Other users are anticipated, but first we need to get past
    > the chicken-and-egg.

    There are no chickens and no eggs.

    utrace is in RHEL4, RHEL5, FC6, FC7, FC8, FC9 kernels already.

    I can't believe RedHat allowed to totally rewrite ptrace based on some
    prototype code.

    > > This all similar to systemtap/markers story. Big changes under
    > > promises that now, now somebody will use our thing.
    >
    > In what way do you think those promises are unfulfilled? Systemtap
    > has interfaced to markers since the beginning,

    It just wants entry point, right?

    > and there are a bunch of markers in the tree.

    Total 3 in scheduler and in spufs (ppc-specific).

    Amazing improvement for ugly macros, more self-modified kernel, explicit
    reasons stated why they are stupid spelt in review and after entering tree,
    and general dislike of some maintainers to add more trace_mark() entries.


    So there were promises that markers will be useful, 10 months passed and
    they are still useless. How did this happen?

    Now utrace is in better position in this respect -- ptrace(2) will use
    it from start but this doesn't change "promises" part.



    \
     
     \ /
      Last update: 2008-08-27 17:35    [W:3.871 / U:0.204 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site