Re: [PATCH 2/3] Always check marker consitency

* Frank Ch. Eigler ([email protected]) wrote:
> 
> Hi -
> 
> > >  		if (flags & MF_LOCKDEP
> > >  			&& !(iter->mdata->flags & MF_LOCKDEP)) {
> > >  			printk(KERN_NOTICE
> 
> Regarding these marker flags, could we make do without this additional
> hard-coded numerical ABI?  How about adding such annotations right
> into the formatting string, for example:
> 
>      mark(subsystem_ticklish, "ticklish %p %p", var1, var2);
> 
> The presence of the "ticklish" string would be taken to require the
> marker client to abstain from any activity that may tickle the
> subsystem.  The lockdep/don't-you-dare-printk flags could appear as
> similar strings.
> 

Hi Frank,

No, it's not possible, because I must use the flags to specify the type
of marker at compile-time (optimized vs generic). The string only offers
verification at probe connexion.

By the way, there is a whole new version coming : I just finished
switching the conditional function call into a separate infrastructure
(conditional call) which looks like :

some code...
  ret = cond_call(myname, myfunc(arg1, arg2));
some other code...

It will permit a much broader use the this core infrastructure : any
function call that must be compiled-in, but only enabled at runtime,
with a very low impact on performances when disabled, can be turned into
a cond_call().

My next step is to reimplement the markers on top of this infrastructure
and then I will be ready to post. The flags are still needed in the
cond_call() infrastructure, so it does not make much sense to discuss
about putting them in the string (which is not used by cond_call()) at
this point.

Mathieu

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68