Re: [Ltt-dev] Linux kernel marker questions

* Frank Eigler ([email protected]) wrote:
> 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?
> 
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
> [email protected]
> 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