Re: [Ltt-dev] Linux kernel marker questions

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi, Mathieu -

> 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. :)

Indeed.

> > > 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.

But the namespace reflects the actual complexity of the system.  If
you defer marker insertion for modules being loaded on-the-fly, then
the code already knows modules are special, and most of the complexity
is already there.

> > 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 [...]

OK.

> (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).

I don't entirely understand the issue with lockdep.  Is the problem
only that it reports errors via printk?  Could you send a pointer to
more detailed information on new atomicity constraints due to lockdep?


- FChE