This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Notes from the systemtap BOF


Michael Raymond wrote:
>     IMHO event markers have meaning separate from their physical location.
> If we have two markers within schedule() and I add an ad hoc one, it
> shouldn't change the "identity" of the previous two.
>     I think that each trace point should have a numeric ID and a textual
> component associated with it.  Whether the textual part comes from the
> kernel or is linked to the ID in some user space DB is of minor importance.
> The ID by itself allows position independence and quick comparison.  It also
> allows ranges to be enabled / disabled which seems more semantically correct
> than a per-file approach.  The text by itself gives human readable meaning.
> If we go with both of them than we should have a policy regarding the
> normalization issues associated with their tuple.

Sorry, I strongly disagree. The fact of the matter is that for any
markers infrastructure to be viable it needs to require zero maintenance.
Having unique IDs (per file or throughout the kernel) is going to require
maintainers to have their eyes going accross the source checking for
consistency. That's not likely to fly.

If there has to be some form of uniqueness, then it's going to come from
the name-tags. User-space tools can then do the rest. And if you add your
own events for debugging, then it's up to you to update the user-space
tools to know about them.

As for range-enable/disable, this is a job for user-space. If you need to
enable "process scheduling" and this is something that, for you, spans
multiple files, then you can have this enable "process scheduling" flag
in user-space enable multiple markers in multiple files in the kernel.
The onus is on user-space, not kernel space.

It's all about maintainability. The way I described it, it costs zero to
maintain for kernel developers, but may require intelligent naming on
our part and good user-space tools.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]