Date: Tue, 25 Dec 2012 19:17:21 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> 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 Subject: Re: svn commit: r244663 - stable/9 Message-ID: <alpine.BSF.2.00.1212251911360.56707@fledge.watson.org> In-Reply-To: <20121225104422.GB53644@kib.kiev.ua> References: <201212241422.qBOEMrcF021632@svn.freebsd.org> <CAJ-VmokV-JL_xZ9otRXubKZ8KQKe7GgLuLU3UMij0HUD_KhCNw@mail.gmail.com> <50D8B533.8080507@mu.org> <20121225104422.GB53644@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1212251911360.56707>