svn commit: r244663 - stable/9

[Garrett Cooper]

On Dec 30, 2012, at 2:31 AM, Pawel Jakub Dawidek <pjd at FreeBSD.org> wrote:

> 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.

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 like 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 the well defined/supported model, s.t. having to focus on this becomes a non-issue.

Thanks,
-Garrett