Re: Path to kmods

[Christoph Egger <Christoph_Egger%gmx.de@localhost>]

Juergen Hannken-Illjes wrote:
> On Wed, Nov 12, 2008 at 05:27:30PM +0100, Hubert Feyrer wrote:
>> On Wed, 12 Nov 2008, Antti Kantee wrote:
>>> I like the Linux naming.  Before your post, I was planning to suggest
>>> /modules, but thought the name is too generic.
>> OK, another idea... maybe that's a bit radical, but so what:
>>
>> Currently, /netbsd is "the stuff that is the kernel". To switch to a new 
>> kernel (for testing, or whatever), I have to replace /netbsd, e.g. by a 
>> symlink to a new/testing kernel, or by replacing the actual file.
>>
>> With a modularized kernel, "the stuff that is the kernel" is basically the 
>> actual kernel plus modules.
>>
>> So, I wonder if we should change /netbsd to a directory that has the 
>> actual kernel plus the modules that are associated with that specific 
>> (actual) kernel.
>>
>> To switch to a new "kernel", I'd have /netbsd either as simple directory 
>> or as symlink to something that has my own naming scheme, just as now.
>> The choice of the naming scheme would be left to the user, and we could 
>> assume to be the "kernel"(-stuff) still be in /netbsd.
> 
> This looks good to me. If we boot a plain file it is a monolitic kernel, if
> we boot a directory it looks like:
> 
>       /netbsd
>               /netbsd/kernel
>               /netbsd/adosfs
>                       /netbsd/adosfs/adosfs.kmod
>               ...
> Next move the modules from the base set to the kernel set(s) and have
> build.sh create full kernel+modules set(s) on "build.sh kernel=XXX".
> 
> That way a kernel switch would be (in both cases):
> 
>       mv /netbsd /netbsd.old
>       tar zxf .../binary/sets/kern-XXX.tgz
> 

Isn't it possible to have the module loading work like autoconf ?

I can imagine to have it working this way:

A module description file is (related to above suggested directory
suggestion) in /netbsd/modules

This file describes the modules: what it matches to and what modules
it depends on.

The module loader can build an internal module chain and it loads the
one which fits best for the kernel in use. Based on this loaded module,
the module loader can recursively load the depending modules the
same way.

This approach allows to have multiple versions in the module search
path.

Note, w/o the description file, all modules in question
must get loaded in order to run the modules' match() function
and unload all modules, but the one which fits. This is not
efficient.

Christoph