svn commit: r244663 - stable/9

[Alfred Perlstein]

On 12/28/12 8:16 PM, Peter Wemm wrote:
> On Tue, Dec 25, 2012 at 11:17 AM, Robert Watson <rwatson at freebsd.org> wrote:
>> 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.
> For what its worth, we used to have an extensible VOP_* interface that
> didn't have this sort of problem. It was removed in r140165 (back in
> 2005) and we gained a whole bunch of extra functionality afterwards
> including type checking.
>
Yes.  Kib and I chatted offline, it seems that the SOP is really "there 
is no guarantee about KPI when talking about VFS" so the headache that 
it would be to write the shim layer and maintain it (particularly 
considering the 9.x release cycle slowness) was not worth it.

In a few days I'm going to blow up the extra entries in VFSOPS and VOPS 
by some 10 entries to hopefully keep us KPI friendly for the next 
release.  I may also introduce a VFS_KPI version number.  Let me know if 
you have any thoughts on that, my thoughts are basically to make it like 
FreeBSD_version, and eventually someone can add macros for VFS klds to 
refuse to load depending on VFS_KPI.

-Alfred