Date: Fri, 28 Dec 2012 20:16:51 -0800 From: Peter Wemm <peter@wemm.org> To: Robert Watson <rwatson@freebsd.org> Cc: Adrian Chadd <adrian@freebsd.org>, src-committers@freebsd.org, svn-src-stable@freebsd.org, svn-src-all@freebsd.org, Alfred Perlstein <bright@mu.org>, svn-src-stable-9@freebsd.org, Konstantin Belousov <kostikbel@gmail.com> Subject: Re: svn commit: r244663 - stable/9 Message-ID: <CAGE5yCp1oVe74_8wot8rJe5BU9uOHyfLipUN0cFtCC77CLo8hA@mail.gmail.com> In-Reply-To: <alpine.BSF.2.00.1212251911360.56707@fledge.watson.org> References: <201212241422.qBOEMrcF021632@svn.freebsd.org> <CAJ-VmokV-JL_xZ9otRXubKZ8KQKe7GgLuLU3UMij0HUD_KhCNw@mail.gmail.com> <50D8B533.8080507@mu.org> <20121225104422.GB53644@kib.kiev.ua> <alpine.BSF.2.00.1212251911360.56707@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 25, 2012 at 11:17 AM, Robert Watson <rwatson@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 - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGE5yCp1oVe74_8wot8rJe5BU9uOHyfLipUN0cFtCC77CLo8hA>