svn commit: r244663 - stable/9

[Robert N. M. Watson]

On 29 Dec 2012, at 06:40, Adrian Chadd wrote:

> There's likely a bunch of companies/users that would love things to
> not change during a stable branch and there's likely a bunch of
> companies/users that would hate things being immutable during a stable
> branch.
> 
> There's never been a formal "kernel ABI stuff in stable shouldn't
> break" or not, but as far as I was aware, the unofficial method was
> "discuss on -stable or -arch to see whether it's worth the break, then
> break it if needed, or not-break it and add a dirty hack for that
> branch" if not.
> 
> This is why things like vimage/vnet were so dirty in the backports, if
> you remember. Julian and others made a specific attempt _not_ to break
> KBI when backporting the feature.
> 
> So, regardless of whether we should or shouldn't break things, a more
> thorough discussion would've been nice.

Adrian:

The standing consensus is that we try not to break certain classes of device drivers, not that we don't ever change any kernel interfaces. The reason is that we don't have a formal definition of "public" and do not wish to use the definition "all definitions in all header files" or "all symbols ever linked by any module" -- that definition would prevent almost any change to the kernel in -STABLE branches at all. The reason VIMAGE/MRT/etc had to be done with great caution is that they directly affected network device drivers, which are a category of module which we have decided we do want to try to support in external binary form. The other major category is binary storage drivers.

When we talked to various VFS maintainers, looked at the past change history there, and looked at the set of third-party file systems (especially, those we could see in ports), the consensus there was that it was too difficult to define a stable VFS KPI and KBI for third-party modules. In particular, there appear to be at most one or two in ports at any given moment, and quick analyses of them suggested that their kernel feature dependency footprint was far more than just "vnode operations".

KPIs and KBIs have benefits and downsides: we need to consider them as a tradeoff space, and not an absolute, and use them where they have significant payoff. Especially as we don't have formal tools for reasoning about or testing them.

Robert