[Ksummit-2012-discuss] [ATTEND] Using SmPL for collateral evolutions *and* backporting

Luis R. Rodriguez mcgrof at frijolero.org
Fri Jun 15 22:42:53 UTC 2012

Quite frankly a lot of the discussions at the last Linux kernel summit
that I attended were way over my head, but there is one topic that I
have been focusing on first because I had an itch to scratch to do it
better than how I saw some companies were doing it and later because
it seemed people wined when I said I'd stop maintaining it:
automatically backporting the kernel.

As the project has evolved through contributions in the community and
discussions there are quite a few lessons learned and quite a bit of
surprises. My biggest surprise was at the last Linux Plumbers
conference where Julia Lawall described to me Jesper Andersen's work
on code which would generate SmPL for you based on two diffs with a
tool called spdiff. The fact that this work is possible has huge
*possible* implications on design / architecture of software that in
my opinion *has not yet been well understood by many people*,
including its own authors. To summarize it, if we can collaterally
evolve the Linux kernel by using SmPL the inverse of the SmPL could
likely be used to *automatically* backport such collateral evolution.
I've already started to redesign some of our patches in
compat-wireless (to be renamed to compat-drivers) to match collateral
evolutions, my first task is to prove that the collateral evolution
that introduced struct net_device_ops could be backported first with a
single line of code for each driver, and as a second step (this is not
related to SmPL) prove that even this one single line could not be
needed at all if we accept an upstream static inline
netdev_attach_ops(). By the time of the kernel summit I hope to have
done all of this homework for at least one collateral evolution. It'd
be great to review this with other kernel maintainers to see if we
want to take into consideration some development style considerations
which can help evolve the Linux kernel with things like SmPL. Given
that this involves Cocci / SmPL / spdiff, I'd also like to drag out
Julia and Jesper to come too.

I hold that backporting is not something that kernel developers should
care about, but if what I am observing is true, we may be able to
consider *some things* for design on the kernel to help with providing
faster deliveries to users of all of our juicy enhancements on drivers
/ features in the Linux kernel.


More information about the Ksummit-2012-discuss mailing list