On 25 December 2012 11:17, Robert Watson <rwat...@freebsd.org> wrote:
> While I would love to have a stable KBI, or even KPI, for VFS, past > experience suggests that we are not prepared to document one, let alone > enforce it, and that we frequently experience changes that disrupt both the > binary and programming interfaces -- often for very good reasons (e.g., > fixing critical bugs, improving performance, etc). And that the notional > VFS KPI is extremely promiscuous, being made up of not just the obvious VFS > parts, but also VM parts, etc. We've done a bit better with device drivers, > where the consensus is that we should Try Fairly Hard, but even there we > have only limited documentation of what even constitutes the KPI and KBI. > In the end, not all kernel interfaces can be "KPIs" or "KBIs" -- otherwise, > we could change almost nothing in -STABLE, causing branches to stagnate > rapidly. If you look at Apple's model (for example), they designate certain > interfaces as "API" or "KPI" rather than using the terms more casually to > refer to any interface in userspace or kernel, and we need to take the same > perspective. A few years ago, I took a gander through a number of core > network stack data structures used by device drivers, while trying to help > resolve how TOE would fit into the network device driver picture, and you > can see the results here: 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 _______________________________________________ svn-src-stable-9@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-stable-9 To unsubscribe, send any mail to "svn-src-stable-9-unsubscr...@freebsd.org"
