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