Re: Revising path to kernel modules

[Andrew Doran <ad%netbsd.org@localhost>]

On Sun, May 10, 2009 at 11:04:11PM +1000, Luke Mewburn wrote:

> Hi folks.

Hi Luke.

Just as a prelude, I am quite aware that modularity affects practices that
have existed for a long time, and that it is quite new to us. It is also a
step away from the practice of "fixing" runtime problems with compile time
knobs and #ifdefs, which is a software development challenge in itself.

> I propose that we change the way we name our kernels and modules.
> This is based off previous discussions on various mailing lists
> (including this one) over the last six or so months.

It was noted that kernel modules have no relation to the kernel image
other than the shared attributes of machine+version.

> * For a given kernel "/netbsd-foo";
>     - The kernel is /netbsd-foo/kernel
>     - The modules are in /netbsd-foo/modules/
>     - The set is netbsd-foo.tgz and contains the above
> 
> * The "path to kernel" that users boot would just be "/netbsd-foo".
> 
> * This scheme should allow for kernels in subdirtories
>   (e.g, "/kernel/foo/bar/{kernel,modules}")
>
> * The boot loader passes in the booted kernel path via an MD method.
>   Most platforms should already have a method to do this; for those
>   that don't we'll need to design and implement improvements to the
>   mechanism that the first (or possibly second) stage boot loaders
>   use to communicate this to the booted kernel.

This would be problematic with TFTP or "kernel on one disk, root on
another".
 
> 
> Benefits:
> 
> * End users can extract one set.tgz to get a new kernel.

End users typically run a release version. The modest guarantee that we can
and must offer is that the kernel ABI will not change in incompatible ways
over the release lifetime, so this is somewhat moot. The picture is
different for those running on the bleeding edge, right.

> * Kernels and the modules they need to function are kept together,
>   and easily manipulated.  For example (where these are directory paths):
>     cd /
>     mv netbsd netbsd.20090910
>     tar zpxf netbsd-GENERIC.tgz
>     mv netbsd-GENERIC netbsd
>     reboot
> 
>     [boot prompt] boot /netbsd
> 
> * Avoiding N more threads initiated by users who update their kernel
>   after a kernel version bump and have an unbootable system because
>   they forgot to update the modules.
>   Or in my case, I didn't start a thread -- I just punted on -current
>   in frustration.

I think in that case we should provide better documentation or enhance the
tooling (build.sh). See work in motion to provide a seperate set for kernel
modules.

Personally, the way I handle this is to leave my old kernels around and not
screw with the installed modules. I think it could be useful to provide an
alternate prefix for kernel developers.

>   arguably "shareable" modules

If you know of outstanding issues please file problem reports. Otherwise I
must view this as handwaving.