svn commit: r244663 - stable/9

[Pawel Jakub Dawidek]

On Sat, Dec 29, 2012 at 08:43:56PM -0800, mdf at FreeBSD.org wrote:
> On Sat, Dec 29, 2012 at 6:38 PM, Benjamin Kaduk <bjkfbsd at gmail.com> wrote:
> > On Sat, Dec 29, 2012 at 5:44 AM, Robert N. M. Watson <rwatson at freebsd.org>
> > wrote:
> >>
> >> 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".
> >
> >
> > If OpenAFS is the only out-of-tree filesystem in ports, then most definitely
> > there are far more dependencies in place.  I don't know how closely Isilon's
> > stuff keeps to our models
> 
> KBI/ABI are not relevant for Isilon since we build universe every
> time.  Changes to the KPI need to be tracked, of course.

I agree that KBI is not that much important to vendors, it is better to
prepare build infrastructure that will compile everything and create
instalation image or upgrade package. KPI is of course totally different
story.

> I don't know if there are other vendors with a custom filesystem who
> are not shipping a whole system (NetApp has a pretty odd use case
> AFAIK).

There are other vendors, but from my experience vendors don't really
follow stable as close as possible. Once "good enough" stable/N revision
is found, vendors will stick to it, most likely until at least
stable/N+1 appears. Most of the time there are no changes significant
enough in stable branch to afford the slide and all the testing. This is
a lot of work and random things can break. Even if there are important
changes, they may also be cherry-picked instead of upgrading everything.
And if the next upgrade is done to stable/N+1, vendor will have to deal
with KPI changes anyway. It is very nice if KPI changes in a way that
code no longer compiles, so changing order of bcopy(9) arguments is not
welcome:)

To sum up, I think stable KPI/KBI is most important for 3rd-party kernel
modules. We don't want them to stop loading once user upgrades because of
security fix and if we can't avoid the breakage UPDATING entry is a
must.

I wonder how many 3rd-party kernel modules do we have in ports. If not
that many maybe we could provide new target to ports' Makefile to just
build kernel modules to verify they at least compile. This would help
catch problems like the recent one with VM KPI change and VirtualBox
modules easier.

As for the KBI, maybe installkernel could verify that modules in
${DESTDIR}/boot/modules/ are compiled for the same __FreeBSD_version and
warn if not?

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
FreeBSD committer                         http://www.FreeBSD.org
Am I Evil? Yes, I Am!                     http://tupytaj.pl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20121230/f1ff04f9/attachment.sig>