Date: Sat, 29 Dec 2012 06:50:54 -0800 From: Adrian Chadd <adrian@freebsd.org> To: "Robert N. M. 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-VmonDbwPkpZL_QdHjr%2Bc2X06_rGD%2Bwy_R%2BxeVBs=hnQ4qTw@mail.gmail.com> In-Reply-To: <00E4FFFA-8ADB-4D43-B977-3834C48133E4@freebsd.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> <CAJ-Vmo=oYfzxwEDYnXotx4b8qvnQTr4ofrLRkwkKH5C9GB0sMg@mail.gmail.com> <00E4FFFA-8ADB-4D43-B977-3834C48133E4@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 29 December 2012 02:44, Robert N. M. Watson <rwatson@freebsd.org> wrote: [snip] >> [adrian chadd] >> 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 dev= ice drivers, not that we don't ever change any kernel interfaces. The reaso= n 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 ev= er 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 d= rivers, 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 hist= ory there, and looked at the set of third-party file systems (especially, t= hose we could see in ports), the consensus there was that it was too diffic= ult to define a stable VFS KPI and KBI for third-party modules. In particul= ar, 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 foot= print 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 significa= nt payoff. Especially as we don't have formal tools for reasoning about or = testing them. Sure, that's a logical, reasoned analysis of what the state of play of the VFS interface and users. But again, it'd have been nice to get some notification before it was pushed to -stable, just as a heads up (and a chance for feedback) for people and companies who aren't on your radar. Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmonDbwPkpZL_QdHjr%2Bc2X06_rGD%2Bwy_R%2BxeVBs=hnQ4qTw>