Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Revising path to kernel modules

On Sun, May 10, 2009 at 9:04 AM, Luke Mewburn <> 
> 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 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?


Home | Main Index | Thread Index | Old Index