Date: Sun, 30 Dec 2012 11:31:05 +0100 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: mdf@FreeBSD.org Cc: Benjamin Kaduk <bjkfbsd@gmail.com>, src-committers@freebsd.org, svn-src-stable@freebsd.org, svn-src-all@freebsd.org, svn-src-stable-9@freebsd.org, "Robert N. M. Watson" <rwatson@freebsd.org> Subject: Re: svn commit: r244663 - stable/9 Message-ID: <20121230103105.GH5028@garage.freebsd.pl> In-Reply-To: <CAMBSHm8fKkxMJZiAxhrO=5tqidEe2LwoqpNGOWvcd0WGJPrPPw@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> <CAJ5_RoBPdENKazPZT4vXibcfN_BUhVViHvOvu0CqcaPx0q1Jvw@mail.gmail.com> <CAMBSHm8fKkxMJZiAxhrO=5tqidEe2LwoqpNGOWvcd0WGJPrPPw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--jaTU8Y2VLE5tlY1O
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Dec 29, 2012 at 08:43:56PM -0800, mdf@FreeBSD.org wrote:
> On Sat, Dec 29, 2012 at 6:38 PM, Benjamin Kaduk <bjkfbsd@gmail.com> wrote:
> > On Sat, Dec 29, 2012 at 5:44 AM, Robert N. M. Watson <rwatson@freebsd.o=
rg>
> > 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 tha=
t 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 kern=
el
> >> feature dependency footprint was far more than just "vnode operations".
> >
> >
> > If OpenAFS is the only out-of-tree filesystem in ports, then most defin=
itely
> > there are far more dependencies in place. I don't know how closely Isi=
lon's
> > stuff keeps to our models
>=20
> 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?
--=20
Pawel Jakub Dawidek http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://tupytaj.pl
--jaTU8Y2VLE5tlY1O
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)
iEYEARECAAYFAlDgF+kACgkQForvXbEpPzRmBQCfV9IBvkbbXtzrF6Yx8Ho3HieW
gigAn0sBYnnDVshnT/SY7uD81w/YWO7j
=teAC
-----END PGP SIGNATURE-----
--jaTU8Y2VLE5tlY1O--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121230103105.GH5028>