Date: Sun, 30 Dec 2012 05:37:02 -0800 From: Garrett Cooper <yanegomi@gmail.com> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: Benjamin Kaduk <bjkfbsd@gmail.com>, "mdf@FreeBSD.org" <mdf@FreeBSD.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-stable@freebsd.org" <svn-src-stable@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-stable-9@freebsd.org" <svn-src-stable-9@freebsd.org>, "Robert N. M. Watson" <rwatson@freebsd.org> Subject: Re: svn commit: r244663 - stable/9 Message-ID: <25D528BC-8D25-4566-9B53-0BF2927ED1B2@gmail.com> In-Reply-To: <20121230103105.GH5028@garage.freebsd.pl> 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> <20121230103105.GH5028@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 30, 2012, at 2:31 AM, Pawel Jakub Dawidek <pjd@FreeBSD.org> wrote:
> 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.or=
g>
>>> wrote:
>>>>=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 a=
t
>>>> any given moment, and quick analyses of them suggested that their kerne=
l
>>>> feature dependency footprint was far more than just "vnode operations".=
>>>=20
>>>=20
>>> If OpenAFS is the only out-of-tree filesystem in ports, then most defini=
tely
>>> there are far more dependencies in place. I don't know how closely Isil=
on'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.
>=20
> 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.
>=20
>> 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).
>=20
> 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:)
>=20
> 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.
>=20
> 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.
open-vm-tools, virtualbox-ose-kmod, fusefs-kmod, and kqemu-kmod* are the big=
pain points I discovered because they generally delve in low-level kpis lik=
e vfs, vm, and newbus.
> 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?
That would be somewhat interesting, but fixing everything to work with PORTS=
_MODULES to ensure that one's kernel and ports klds are in synch should be t=
he well defined/supported model, s.t. having to focus on this becomes a non-=
issue.
Thanks,
-Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25D528BC-8D25-4566-9B53-0BF2927ED1B2>