On Sun, May 08, 2016 at 09:23:03PM +0200, Luis R. Rodriguez wrote:
> On Sun, May 08, 2016 at 07:50:23AM -0400, Sasha Levin wrote:
> > On 05/06/2016 07:26 PM, Luis R. Rodriguez wrote:
> > > Julia and I had discussed the possibility to instrument Linux code as
> > > an alternative to complex debugging strategies (lockdep is one) that
> > > often may be frowned upon due to how intrusive some changes may be or
> > > how much extra stuff would be needed upstream. It has been hard to
> > > explain the idea to folks who might make some use of it so I've gone
> > > ahead and created a demo tree for userspace code that shows some basic
> > > instrumentation ideas. You can fetch it here:
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/cocci-tact.git
> >
> > Thanks Luis! I haven't reviewed it yet, just Cc'ing Quentin and Vegard
> > who are also working on the lock poisoning patchset.
>
> Another strategy can be to do instrumentation internally in Coccinelle
> with the help of its standard rule dependency or extending use by
> using Python scripting for a replacement for internall book keeping.
>
> The patch below is a simple alternative to adding C instrumentation
> code but instead it actually tries to fix the code given a certain
> set of conditions and rules.
<-- snip -->
Lastly, it just occurred to me that if a set of Coccinelle scripts
do not suffice (I mentioned two options for instrumentation), another
alternative building off of the first Coccinelle approach I mentioned
would be to complement that with *new code* and *regular patches* that
would otherwise simply not be appropriate with just Coccinelle. For
instance, take the addition of code which initializes the instrumentation,
or helpers definitions which may be generic. This need not belong in
each piece of kernel code but perhaps more in a generic place, and if
not upstream, one alternative can be a kernel complement framework to
enable both to co-exist. It took me a bit to realize that we already
have this... but once I realized it, it became an obvious alternative:
the Linux backports infrastructure [0] already enables:
a) serializing applying regular patches, and
b) if one finds generalization rules also serializes
applying series Coccinelle SmPL patches
c) adding custom code which any of the above can use
through its own module (compat)
d) enables for module replacements (using depmod.d updates/),
so your distro has iwlagn for v3.5, backports lets you get
iwlagn update from code as of v4.3 [1]
e) enables as an alternative kenrel integration [2]
In a way, the backports infrastructure provides a framework to let
you roll out your own customized Linux distribution but with utmost
focus upstream. For backports this makes sense -- we just re-use
upstream and port. We do this as backporting is not welcomed upstream
as it would mean having to add tons of nasty #ifdefs, and helper code..
sound familiar? Instrumentation code which may be considered
"too intrusive to have upstream" is another possible candidate
that can benefit from it given all the bells and whistles have been
ironed out already -- we strive to automate backporting ;)
Now granted, we didn't set out to write backports to make it a generic
framework, but -- its there, and if you guys have such an interest
I think we can both benefit from collaborations... that is unless
you do find a reasonable way to just shove everything upstream.
[0] https://backports.wiki.kernel.org
[1] https://backports.wiki.kernel.org/index.php/Documentation/packaging
[2] https://backports.wiki.kernel.org/index.php/Documentation/integration
Luis
_______________________________________________
Cocci mailing list
[email protected]
https://systeme.lip6.fr/mailman/listinfo/cocci
