Re: [PATCH] Linux Kernel Markers 0.2 for Linux 2.6.17

[Karim Yaghmour <karim at opersys dot com>]

Frank Ch. Eigler wrote:
> If the decision you're talking about is whether all markers in the
> system should behave one way or another, then this is a degree of
> central control that we have not contemplated during the entire
> thread, until now.
> 
> It is an end-user such as an administrator who will figure out which
> probes/markers/tracing elements need what kind of processing attached.
> They don't want to recompile the kernel to switch.  They will want
> different types of processing, or none at all, for different markers
> during a system lifetime.

Sure. I'm sure there's just a slight miscommunication here because
my understanding of Mathieu's attempts goes in the direction of
what you're saying here. He might not have gotten it right, but
that can be worked on.

> This line of thinking makes me worry that we've forgotten all that we
> learned during the weekend.  Amongst the insights apparently agreed
> was that on *any given system*, a mixture of static an dynamic probing
> was likely necessary.  For the static part of the instrumentation, a
> marker that could be hooked up to either type of probing system was
> desirable, which implies some sort of run-time changeability.

Ok. So if I get what you're saying here, you'd like to be able to
overload a marker? Can you suggest a macro that can do what you'd
like. I'm sure Mathieu would gladly take a close look at it.

> That's if it works, if it can be implemented, if it does not create
> conflicts between multiple tracing/probing systems, if ...  
> 
> Yes, in theory it might bridge the gulf between compile-time and
> run-time configuration, but aren't these all big "if"s right now?

Lots of "if"s in this thread, and this weekend does teach us that
highlighting the problems with other peoples' "if"s is dangerous.
I'm sure you'd agree that concentrating on the areas where there
is agreement would be best.

> I don't understand how this new compile-time configured style of
> marker is to serve anyone who wants to use something other than a
> single distribution-picked tracing/probing tool.  I though we had
> abandoned that model some time ago.

We did, and I'm sure there's a fundamental misunderstanding here.
It would likely help if you could give a concrete example of how
you would like Mathieu's proposal be changed or, if you don't
like it at all, what you would like to see. Anything purely
technical that will avoid any of the pitfalls generated by
differences in perspective.

Thanks,

Karim