svn commit: r244663 - stable/9

[Adrian Chadd]

On 25 December 2012 11:17, Robert Watson <rwatson at 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