Re: Notes from the systemtap BOF

[Karim Yaghmour <karim at opersys dot com>]

Michael Raymond wrote:
>     If I were to rewrite the scheduler I would need to move the trace points
> to the appropriate place.  I think it is therefor more correct to say that
> we desire an interface with the minimum possible maintenance required.

Sure.

>     You've pointed out that we don't want developers to have to look for
> name collision, and we want to be able to refer to trace points by some
> number.  File / function location gets us close to this but has the downside
> that meaning should be separate from location.

Sure.

>     We need to support core events and ad hoc exploration.  If I were adding
> a new piece of code that I'd like traced, I'd like to have the option to
> have it show up as some standard event or just be some temporary trace that
> I'll remove later.

Hmm... I guess I kind of understand what you're trying to achieve: make it
simple for people to add ad-hoc trace points that don't require user-space
tool modifications to make them meaningfull. I can see the usefullness of
this, but ... more below.

>     Perhaps we can find a compromise.  Many tools and we ourselves currently
> have a central .h file that defines standard events.  If it's simple and
> well layed out then people will use it and won't need to modify it.  For
> other trace points I think that position based IDs are fine.

Ok, this basically boils down to what will and will not be acceptable to
kernel developers. Sure, there's no way to know until we post it, but based
on my experience on being on the LKML for the past 6+ years my take on this
is that it often comes down to "who's using this today?". If we take the
position-based approach to markers, then having a parallel mechanism will
prompt the question "why do you have two mechanisms to identify events?".
And if we bring up the problem of future ad-hoc tracing, we'll likely be told
that we're adding a feature that has no present use. Plus, if it's ad-hoc,
then it's a kernel development problem ... "wait, if it's for kernel
development then it doesn't belong inside the kernel." Been there, seen that.

Yes, I know, this is all subjective. However, I'd really like us to take
the conservative approach. That'll be the one that guarantees the greatest
chance of success. And the conservative approach is to divert work to
user-space in as much as possible. IOW, I really think that if a user is in
the process of adding ad-hoc instrumentation, the burden should be on her/
him to mirror the understanding of those markers to user-space. Granted,
we should make this job as easy and as straight-forward as possible, and
maybe we'll actually have tools that do not require the ad-hoc instrumentor
to go around adding more stuff in user-space, but in all cases we should
architecture the kernel-side so that it leaves very little space for
criticism or confusion.

Hope this clarifies the angle I'm approaching this with a little.

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546