Date: Fri, 28 Dec 2012 22:40:10 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Robert Watson <rwatson@freebsd.org> Cc: 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: <CAJ-Vmo=oYfzxwEDYnXotx4b8qvnQTr4ofrLRkwkKH5C9GB0sMg@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 25 December 2012 11:17, Robert Watson <rwatson@freebsd.org> wrote: > 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: There's likely a bunch of companies/users that would love things to not change during a stable branch and there's likely a bunch of companies/users that would hate things being immutable during a stable branch. There's never been a formal "kernel ABI stuff in stable shouldn't break" or not, but as far as I was aware, the unofficial method was "discuss on -stable or -arch to see whether it's worth the break, then break it if needed, or not-break it and add a dirty hack for that branch" if not. This is why things like vimage/vnet were so dirty in the backports, if you remember. Julian and others made a specific attempt _not_ to break KBI when backporting the feature. So, regardless of whether we should or shouldn't break things, a more thorough discussion would've been nice. Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=oYfzxwEDYnXotx4b8qvnQTr4ofrLRkwkKH5C9GB0sMg>