On Sat, 7 Jul 2012 20:54:12 -0600 Warner Losh <i...@bsdimp.com> 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