This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [Ltt-dev] Linux kernel marker questions
* Frank Eigler (fche@redhat.com) wrote:
> 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?
>
If the format passed to marker_arm_probe is not NULL, each marker will
be checked to match the same format. If not, connexion fails.
>
> > [...] 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)?
>
You could pass a module name to the marker_arm_probe then, instead of a
struct module*. Since marker_arm_probe sits in module.c, it makes things
easy. :)
> > 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.
>
Hrm, what if you use a semantic like "module_name__subsys_event" in the
marker names ? You could then control marker activation per module if
you like without adding any complexity to the marker infrastructure.
> > > 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.
>
ok, so if you do not call things like local_irq_enable, nor fall into
debug traps in the handler, you can use the CF_DEFAULT flag for the
marker_arm_probe when you arm your probe : it will imply that your probe
handler won't call into lockdep nor call printk. (meaning that you have
to do everything atomically and, if you _really_ need to do such things
like disabling interrupts, you must use the raw versions which does not
call lockdep).
> > [...] 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.
>
My feeling it that it should probably go into mainline for 2.6.23, but
things should settle down sooner.
>
> - FChE
> _______________________________________________
> Ltt-dev mailing list
> Ltt-dev@listserv.shafik.org
> http://listserv.shafik.org/mailman/listinfo/ltt-dev
>
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68