[lkml]   [2008]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 0/2] utrace
    On Tue, Aug 26, 2008 at 03:01:02PM -0700, Roland McGrath wrote:
    > utrace is a new kernel-side API for kernel modules, intended to make it
    > tractable to work on novel ways to trace and debug user-mode tasks.

    Finally! Familiar code! :^)

    > A previous utrace prototype was in all Fedora kernels since Fedora Core 6.
    > Some substantial implementation and API details in the current code are
    > different from those past versions.

    And some internal details still horrible and overdesigned just like at
    the very beginning.

    > Please look freshly at these patches.

    Well, all comments on tracehook patches were ignored.

    > This code cannot be enabled without CONFIG_HAVE_ARCH_TRACEHOOK and the arch
    > details it indicates. In Linus's tree as of v2.6.27-rc4, only powerpc and
    > sparc64 have that support. The x86 support is available by merging in the
    > tip/x86/tracehook branch. For working on other arch support, there are some
    > more details at and
    > these are mentioned in the comments in arch/Kconfig too (in v2.6.27-rc4).
    > The first patch adds the utrace kernel API (if CONFIG_UTRACE=y is set).
    > There is no change at all without the config option, and with it there is
    > no effect on anything at all until a kernel module using the utrace API is
    > loaded. There is detailed documentation on the API in DocBook form.
    > The second patch adds the CONFIG_UTRACE_PTRACE option.

    If config option for ptrace is fine, please name it CONFIG_PTRACE.
    For one, there will be no second tracing infrastracture. For two, nobody
    but one man on the planet really cares how ptrace(2) is implemented.

    > When set, this makes ptrace use the utrace API as much as is necessary so
    > that using both ptrace and utrace to debug the same threads at the same time
    > won't become confused. The ptrace changes are somewhat kludgey. They're
    > intended to be the simplest, non-regressing thing that suffices to enable
    > hacking on new utrace modules while also doing normal ptrace-based debugging.
    > The ptrace implementation can still use many more cleanups later on.

    General comments:

    On the good side is per-task struct operation. This is good and should
    be required from any such tracing facility.

    Linked list of attached tracers? I don't know.

    One the bad side, where are those nice tracing modules? Where are they?

    I've heard rumours utrace is needed for frysk and frysk people were
    pretty damn silent on linux-kernel.

    On the homepage there is module which frozes task right before coredump.
    AFAICS, Al Viro mentioned that non-schedulable TASK_BROKEN should be
    sufficient for this without wasting all that time that went into
    ptrace(2) stabilization and fixing holes in it.

    This all similar to systemtap/markers story. Big changes under promises
    that now, now somebody will use our thing.

    General reminder:
    people who collected ptrace(2) exploits proggies, try them again.

    Now to code.

     \ /
      Last update: 2008-08-27 00:35    [W:0.025 / U:0.320 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site