Fwd: (PR11207) Macroprocessor discussion

[Serguei Makarov <smakarov@redhat.com>]

[oops, that should have been reply-to-all. Resending to the main mailing list:]

Frank,

All right, I agree with most of those suggestions.

The kernel-doc 'glue to previous comment' trick can be an acceptable stopgap while we decide whether/how to implement any deeper magic.

I'm not 100% sold on the special '%define ... %end' syntax, but I'm sufficiently sold to try implementing it :). Perhaps if we're taking that route we could go one step further and have it be

%define foo(bar,baz) {
   ... body of macro, where we track nested brackets {} correctly ...
}

(the important thing to note here being that we need to be smart about not counting brackets inside, say, string literals for determining the nesting depth)

or perhaps %macro foo(bar,baz) { ... }, to make it almost completely consistent with the probe and function syntax. (If it's still called %define, it's still fairly trivial to distinguish it from the %define(...) case -- one has a space after 'define', the other has a paren.)

So, basically, the next step is to figure out a minimal subset of functionality. I'm thinking:
- basic macro invocation syntax
- %define and %undef builtin macros
- the special %define ... %end syntax (whatever variation of it we decide on)
- kernel-doc glue comments (as a last-minute bonus)

This would be enough to rewrite, say, netfilter.stp to avoid having redundant code, with a minimum of fuss and time spent working on the macroprocessor. The basic scheme for doing so would be a wee bit messy, since each probe alias definition would look like this:

/** Specific docs */
%common_docs(blah)
/*** More specific docs */
probe netfilter.foo = ... {
   %netfilter_probe_body(blah)
}

... which is still miles better than the existing copypasta.