Date: Sat, 29 Dec 2012 10:44:43 +0000 From: "Robert N. M. Watson" <rwatson@freebsd.org> To: Adrian Chadd <adrian@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: <00E4FFFA-8ADB-4D43-B977-3834C48133E4@freebsd.org> In-Reply-To: <CAJ-Vmo=oYfzxwEDYnXotx4b8qvnQTr4ofrLRkwkKH5C9GB0sMg@mail.gmail.com> 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> <CAJ-Vmo=oYfzxwEDYnXotx4b8qvnQTr4ofrLRkwkKH5C9GB0sMg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 29 Dec 2012, at 06:40, Adrian Chadd wrote: > 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. >=20 > 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. >=20 > 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. >=20 > So, regardless of whether we should or shouldn't break things, a more > thorough discussion would've been nice. Adrian: The standing consensus is that we try not to break certain classes of = device drivers, not that we don't ever change any kernel interfaces. The = reason is that we don't have a formal definition of "public" and do not = wish to use the definition "all definitions in all header files" or "all = symbols ever linked by any module" -- that definition would prevent = almost any change to the kernel in -STABLE branches at all. The reason = VIMAGE/MRT/etc had to be done with great caution is that they directly = affected network device drivers, which are a category of module which we = have decided we do want to try to support in external binary form. The = other major category is binary storage drivers. When we talked to various VFS maintainers, looked at the past change = history there, and looked at the set of third-party file systems = (especially, those we could see in ports), the consensus there was that = it was too difficult to define a stable VFS KPI and KBI for third-party = modules. In particular, there appear to be at most one or two in ports = at any given moment, and quick analyses of them suggested that their = kernel feature dependency footprint was far more than just "vnode = operations". KPIs and KBIs have benefits and downsides: we need to consider them as a = tradeoff space, and not an absolute, and use them where they have = significant payoff. Especially as we don't have formal tools for = reasoning about or testing them. Robert=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00E4FFFA-8ADB-4D43-B977-3834C48133E4>