On 29 December 2012 02:44, Robert N. M. Watson <rwat...@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 _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
