Re: Revising path to kernel modules

[matthew sporleder <msporleder%gmail.com@localhost>]

On Sun, May 10, 2009 at 9:04 AM, Luke Mewburn <lukem%netbsd.org@localhost> 
wrote:
> Hi folks.
>
> 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.
>
> * 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.
>
>
> Benefits:
>
> * End users can extract one set.tgz to get a new kernel.
>
> * 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.
>
>
> Costs:
>
> * More disk space used by default when using multiple kernels of
>  the same architecture and kernel version, for each extra copy
>  of the arguably "shareable" modules in this case.
>  For the general end-user case, even those following -current, I
>  don't think this is a big issue.
>
> * Kernel developers who like to share pre-built GENERIC modules
>  on their heavily modified debug kernels won't get this by default.
>  Nothing prevents replacing /my-debug-netbsd/modules/ with a symlink
>  to /netbsd.GENERIC/modules/, thus retaining that benefit :-)
>
>
> Changes required:
>
> * Bootloader changes for all the platforms.
>
> * Kernel build support (in the sys/arch directories) to do this.
>

I remember liking this directory-structure proposal a lot when it came
out, but I think there were two big complaints about it:

1) It ties modules to their kernels instead of simply the kernel version.

2) there is an issue with xen that I didn't fully grasp where it drops
a sysctl or multiboot option.

Personally I think the point/counterpoint to problem #1 are really
arguments for system packages, as either scheme has about the same
cost for kernel upgrades OR cost for kernel customizations.

If build.sh kernel and releasekernel were producing kernel.tgz with
/netbsd /stad/x.y.z/ and /etc/mtree/set.kernel, would you be as
inclined to worry about the locations of these files?

Matt