lkml.org 
[lkml]   [2002]   [Sep]   [22]   [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
    Hi,

    On Sun, 22 Sep 2002, Ingo Molnar wrote:

    > Eg. for the scheduler i wrote a simple tracer, but the rate of
    > trace points that started to make sense for me from a development and
    > debugging POV also made kernel/sched.c butt-ugly and unmaintainable, so i
    > always kept the tracer separate and did the hacking in the untained code.
    >
    > also, the direction things are taking these days seems to be towards
    > hardware-assisted tracing. Ie. on the P4 we can recover a trace of EIPs
    > traversed by the CPU recently. Stuff like this is powerful and can can
    > debug bugs that cannot be debugged via software.

    To summarize: You find tracing useful, but software tracing is only of
    limited value in areas you're working at.
    What about other developers, which only want to develop a simple driver,
    without having to understand the whole kernel? Traces still work where
    printk() or kgdb don't work. I think it's reasonable to ask an user to
    enable tracing and reproduce the problem, which you can't reproduce
    yourself.

    > It does have its uses, no doubt, but usually we apply
    > things to the kernel that have either a positive, or at worst, a neutral
    > impact on the kernel proper - kernel tracing clearly is not such a
    > feature.

    Last time I checked it has no impact on the kernel as long as it's not
    enabled. Anyway, it would already be very useful to have at least the core
    integrated. How many drivers currently define a "dprint"? Some even
    implement its own tracing. While debug prints are mostly useful during
    early development, they are usually completely useless, when you have to
    reproduce a problem.

    > so use the power of the GPL-ed kernel and keep your patches separate,
    > releasing them for specific stable kernel branches (or even development
    > kernels).

    While I agree that this acceptable approach for things like kgdb, I think
    it would very useful to have at least the tracing core in the kernel.

    bye, Roman

    -
    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:2.773 / U:0.052 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site