svn commit: r244663 - stable/9

[Adrian Chadd]

On 29 December 2012 02:44, Robert N. M. Watson <rwatson at freebsd.org> wrote:

[snip]

>> [adrian chadd]
>> 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.

Sure, that's a logical, reasoned analysis of what the state of play of
the VFS interface and users. But again, it'd have been nice to get
some notification before it was pushed to -stable, just as a heads up
(and a chance for feedback) for people and companies who aren't on
your radar.



Adrian