Re: Path to kernel modules (second attempt)

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Sat, 7 Jul 2012 20:54:12 -0600
Warner Losh <imp%bsdimp.com@localhost> wrote:

> But it kinda fails with multiple kernels.  On FreeBSD, we went with 
> /boot/$KERNNAME/kernel for the kernel, with all the modules associated with 
> it in /boot/$KERNNAME. By default, we load /boot/kernel/kernel and the loader 
> may also choose to load other things.  The reason we put it in /boot was 
> because we have a secondary boot loader (/boot/loader) and on some platforms 
> we were looking at you needed a separate boot partition to do things 
> correctly.  this layout allows for that as well as transparently supporting 
> multiple kernels.  I know on one of my MIPS boards, I can read kernels or the 
> boot loader off of FAT partitions, so my /boot there is a FAT file system, 
> with the rest of the system in a UFS file system on separate 
> partitions/slices on my CF.

I think that the version and arch directories would be maintained.

But you're right, and when I think of it, it's actually one of the
reasons I use monolithic kernels.  If modules and kernels always
corresponded well and were closely coupled in a directory, it'd be much
less trouble for me to test and move kernels around, or maintain
multiple versions of them on the same host.  At the moment, single
monolithic files do this much better.  Some kernel configuration
changes not only affect the main image, but also the modules, and full
ABI compatibility would be a difficult problem.

It might not matter for someone who wants to avoid using a custom
kernel (I agree that modules should help a lot in this case for the end
user, no matter their arrangement).  But if we eventually begin to see
modules under non-BSD licenses which can only be distributed as
modules, more tech users might likely want modules as well...  Or it
might not matter at all, if an admin can simply link together all
modules in a single kernel image, and keep the non-distributable image
private in the organization (I think there is some work in this area,
other than the traditional monolithic builds)?

So something like /kmod/amd64/6.0/GENERIC/, or a layout
where /netbsd-GENERIC/ could be a directory, /netbsd-GENERIC/image the
kernel, /netbsd-GENERIC/modules/ its corresponding modules, would be
nice.  In the latter case, prehaps also a /netbsd symlink pointing to
the corresponding /foo/image, somewhat like the vmlinuz link of some
Linux distributions?

Thanks for sharing your experience,
-- 
Matt