On Tue, Dec 25, 2012 at 11:17 AM, Robert Watson <rwat...@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. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE _______________________________________________ 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"
