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>