This is the mail archive of the systemtap@sourceware.org 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: Linux kernel marker questions


Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> writes:

> [...]  Yes. A marker can be declared more than once, but bears the
> same semantics and should have the same parameter types.

Will the registration API do the right thing with enforcing this?


> [...]  Correct. It could be fixed by adapting _marker_set_probe,
> making it take an optinional struct module* argument. [...]

Unfortunately, it is hard to get a struct module* by a module.  When
last year, we tried to submit a plain module_get_byname() api call, it
got blocked.  Should we try again (with the same patch, natch)?

> forthcoming markers version though, since I keep a data structure of the
> active markers throrough the kernel, so that if a marker is set before a
> module is loaded, the marker will be activated at module load time.

OK, but we will probably still need a separate namespace.

> > 2) _marker_set_probe() expects the marker name, format string, and flags 
> > that were specified when the marker was inserted.  If marker names were 
> > truly unique, I would really only need the marker name to enable a marker.
> 
> format string and flags are only there to make sure nobody writes
> foolishly a "bad" probe [...]

For a client such as systemtap, marker probes will be atomic.

> [...] Please keep in mind that these sections and data structures
> will change in the forthcoming markers version. [...]

I hope it settles down soon.  If it doesn't, it will become necessary
to add versioning tags to the marker data so we can guide our decoder.


- FChE


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