Re: [PATCH] Linux Kernel Markers 0.11 for 2.6.17

[Mathieu Desnoyers <compudj at krystal dot dyndns dot org>]

Hi Frank,

* Frank Ch. Eigler (fche@redhat.com) wrote:
> Mathieu Desnoyers <compudj@krystal.dyndns.org> writes:
> 
> > [...]
> > > I believe [printf formatting directives] are not
> > > quite general enough either e.g. to describe a raw binary blob.
> >
> > If you want to dump a raw binary blob, what about :
> > MARK(mysubsys_myevent, "char %p %u", blobptr, blobsize); where %p is
> > a pointer to an array of char and %u the length ?
> 
> That involves new conventions beyond printf.  Why not "%p %p %u %u"
> for two blobs ... or why implicitly dereference the given pointers.  A
> probe handler unaware of a specific marker's semantics would not know
> whether or not this is implied.
> 

The idea is to be able to access to a data unit (here, a bin blob) described in
one or more consecutive statements in the string. Why doing %p %u %p %u for two
binary blobs ? Suppose you are creating a probe sub-function that takes a
va_list as parameter and has to extract a such a bin blob. It will expect one
pointer and a size. It simply has to get them sequentially with va_arg. It makes
things much more difficult if you decide to put all the sizes at the end.

So yes, there is a semantic to create, but I don't see the problem with that.

And why would the probe actually know what to do with a pointer ? If it only
wants to record the pointer's address or if it wants to access data inside this
pointer, it's up to the probe (or automatic probe generator, hum ?) to do it.

> 
> > My idea is to use the string to identify what is referred by a
> > pointer, so it can be casted into this type with some kind of
> > coherency between the marker and the probe.
> 
> I understand what you're using them for.  To me, they just don't look
> like a good fit.
> 
> 
> > > I realize they serve a useful purpose in abbreviating what otherwise
> > > one might have to do (like that multiplicity of STAP_MARK_* type/arity
> > > permutations).  [...]
> > 
> > I think that duplicating the number of marker macros could easily make
> > them unflexible and ugly. [...]
> 
> Inflexible and ugly in what way?  Remember, the macro definitions can
> be automatically generated.  At the macro call site, there needs to be
> little difference.
> 

I don't expect the kernel programmer community to accept that their code will
call an automatically generated macro. It removes all the idea of "I can see
what code is actually generated by my function", which I believe is necessary.

Also, people are used to the simplicity and flexibility of printf style format
strings. Do you really expect people to start using various macros like 
MARK_u_p_llu and start defining their own marker macro each time they want to
add a specific type ?

> 
> > [...]  Good point, I will setup a va_args in the probe.  When
> > correctly used, however, there is no need to use the format string :
> > we can directly get the variables from the var arg list if we know
> > in advance what the string will be.
> 
> Do I understand you correctly that the probe handlers would be given
> va_list values, and would have to call va_arg to yank out individual
> actual arguments?

Yes. I want to minimize the visual impact of the marker in the code while
making it self-describing and easy to inspect by a kernel programmer.

> So again type safety is a matter of explicit coding
> (equivalent to correctly casting each type)?
> 

If someone chooses to create their own probes, yes, they must to exactly that.
However, if you want to create probes that are type-safe, you can then create a
script that will extract all the format strings in the markers section of the
object and automatically generate all the probes with their respective va_args
setup at the beginning of the probe. By using the string verification upon
connexion of the probe, type safety should be insured.

My point is that type safety should not exclusively be the marker mechanism's
burden : there are other tools (probe generators) involved in that process.

Mathieu


OpenPGP public key:              http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint:     8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68