svn commit: r244663 - stable/9

[Robert Watson]

On Tue, 25 Dec 2012, Konstantin Belousov wrote:

> On Mon, Dec 24, 2012 at 12:04:03PM -0800, Alfred Perlstein wrote:
>> On 12/24/12 11:24 AM, Adrian Chadd wrote:
>>> ... why'd we break the KBI in a stable branch?
>>>
>> I am not sure either.
>>
>> I think a single VOP for nullfs (while ugly) would have sufficed.
> No, it doesn't.
>
> Even if it would be sufficient, having a switch right after the vtable call 
> is silly. But, ignoring the sillyness, having a single VOP forces a 
> filesystem, needed to override the single bit of behaviour, to override all 
> behaviours hidden from under the common VOP. Besides the incovenience, it 
> breaks the bypass. This is why I did not went this route in the HEAD commit.
>
> Making HEAD and stable diverge for the VOP table is unmaintainable.
>
> At least one other change which cannot be covered by the VOP table hacking 
> is the struct vfsops new method.
>
> Traditionally (my memory goes back to 6.x branch) we did not maintained VFS 
> KBI stability on the branches.

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:

   http://wiki.freebsd.org/NetKPIKBI

However, I didn't attempt to enumerate symbols, just data structures -- that 
was in large part because the issue we faced at the time was changes 
disrupting monitoring interfaces used by netstat (etc).  If we do want to 
chase this goal more formally, we should investigate tools to help us do that.

Robert