Re: Linux kernel marker questions

Frank Eigler <[email protected]>
Newsgroups gmane.linux.systemtap,gmane.linux.kernel.tracing
Message-ID <[email protected]>
Mathieu Desnoyers <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.