lkml.org 
[lkml]   [2009]   [Mar]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH 2/3] utrace core
    Date
    > I'd be interested in seeing a bit of discussion regarding the overall value
    > of utrace - it has been quite a while since it floated past.

    Me too!

    > I assume that redoing ptrace to be a client of utrace _will_ happen, and
    > that this is merely a cleanup exercise with no new user-visible features?

    Yes. It's my expectation that Oleg and I will do that clean-up in
    several small stages, in the not-too-distant future. I think more of
    that work has to do with making the ptrace data structures clean and
    sane than with utrace details.

    > The "prototype utrace-ftrace interface" seems to be more a cool toy rather
    > than a serious new kernel feature (yes?)

    I don't personally have any experience with either Frank's utrace-ftrace
    widget or with using any ftrace-based things to debug user programs.
    I would guess it is more of a demonstration than a tool people will be
    using in the long run.

    > If so, what are the new killer utrace clients which would justify all these
    > changes?

    I hope I can leave those examples to the people who will write them.
    utrace will be a failure if it only serves to underlie the things I want
    to implement or can think up. My intent is to open up this area of new
    feature generation to the people who are killer hackers, but have been
    daunted or turned off by the prospect of becoming killer ptrace innards
    hackers. (Only Oleg seems to have taken to that opportunity, or perhaps
    he expected to wind up doing it as little as I did.)

    > Also, is it still the case that RH are shipping utrace? If so, for what
    > reasons and what benefits are users seeing from it?

    Fedora Rawhide has this current code, yes. The people trying to
    develop new features using utrace certainly like having it there.
    (There really truly are people who like to build novel kernel modules
    without compiling their own kernels from scratch.) I won't try to
    speak for them or their users.

    > And I recall that there were real problems wiring up the Feb 2007 version
    > of utrace to the ARM architecture. Have those issues been resolved? Are
    > any problems expected for any architectures?

    That was a misimpression. There were never real problems for ARM,
    only misunderstandings. I'm sure the way I tried to stage the changes
    at that time contributed to those misunderstandings arising as they
    did. Since then, all the arch requirements have been distilled into
    the HAVE_ARCH_TRACEHOOK set that is already merged for several
    architectures. It is in the hands of each arch maintainer to update
    their code to meet the HAVE_ARCH_TRACEHOOK requirements (I'm glad to
    give advice when asked), and there is no porting work that is actually
    specific to utrace itself. (You just can't turn it on without
    HAVE_ARCH_TRACEHOOK.) Of course it is never all that unlikely that
    some bits of the generic code will get some new tweaks brought to
    light by making it work with a particular arch. To my knowledge, the
    strangest arch for cleaning up any of this stuff has always been ia64,
    and sparc second; those arch maintainers have already done the
    HAVE_ARCH_TRACEHOOK work.


    Thanks,
    Roland


    \
     
     \ /
      Last update: 2009-03-23 05:39    [W:0.031 / U:30.204 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site