Date: Sun, 30 Dec 2012 13:32:24 +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: <A3EF8AB1-3F16-49A6-9094-BD741438F506@freebsd.org> In-Reply-To: <CAJ-VmonDbwPkpZL_QdHjr%2Bc2X06_rGD%2Bwy_R%2BxeVBs=hnQ4qTw@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> <00E4FFFA-8ADB-4D43-B977-3834C48133E4@freebsd.org> <CAJ-VmonDbwPkpZL_QdHjr%2Bc2X06_rGD%2Bwy_R%2BxeVBs=hnQ4qTw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 29 Dec 2012, at 14:50, Adrian Chadd wrote:
>> 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.
>>=20
>> 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".
>>=20
>> 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.
>=20
> 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.
Unless a module is in one of the narrow class of {network, storage} =
device drivers, then third parties should expect to always recompile any =
locally compiled modules, and always perform an analysis of whether =
local kernel extensions are affected by upstream changes.
Remember that the interfaces for "file systems" aren't just the vnode =
interface -- it's also interfaces to VM, the buffer cache, the network =
stack, in-kernel and file system-related locking, quotas, ACLs, IPC, =
etc. A key reason why we are moving FUSE into the tree is to provide =
easier access to file system extensions without having them depend on =
kernel-internal interfaces.
We provide a detailed change log for the kernel via Subversion and its =
associated mailing lists, and that's the best (only) reference for =
granular changes to our tens of thousands of kernel-internal interfaces.
Robert=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A3EF8AB1-3F16-49A6-9094-BD741438F506>