svn commit: r244663 - stable/9

[Robert N. M. Watson]

On 29 Dec 2012, at 14:50, Adrian Chadd wrote:

>> 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.


Unless a module is in one of the narrow class of {network, storage} device drivers, then third parties should expect to always recompile any locally compiled modules, and always perform an analysis of whether local kernel extensions are affected by upstream changes.

Remember that the interfaces for "file systems" aren't just the vnode interface -- it's also interfaces to VM, the buffer cache, the network stack, in-kernel and file system-related locking, quotas, ACLs, IPC, etc. A key reason why we are moving FUSE into the tree is to provide easier access to file system extensions without having them depend on kernel-internal interfaces.

We provide a detailed change log for the kernel via Subversion and its associated mailing lists, and that's the best (only) reference for granular changes to our tens of thousands of kernel-internal interfaces.

Robert