On Sun, 22 Oct 2000, Michael Richardson wrote:

>> Whether the kernel is static or dynamic should just affect when the
>> modules are linked, not what acutally happens.  Unless there is a
>> significant performance difference, it isn't worth being able do to things
>> both ways.
> 
>   Please explain further.
>   There are significant reliability and maintenance issues with dynamic
> loading. Witness DLL rot, and Linux in general.

  I think it depends on the API used.  vfs is a good example of the type
of abstraction you need to do dynamic loading: only the implementation of
a file system should care what filesystem it actually is; the rest of the
kernel should just depend on the properties of that filesystem that are
accessed the same way for all filesystems.  NetBSD has done quite well in
this area; the main issue is places where there are #ifdef MYDRIVER or #if
NFOO > 0, which currently fall into two main catagories:  adding something
to a static array and conditonally including code that calls the
appropriate functions at the right time. 

  The static arrays need to be replaced with a different mechanism that
allows dynamic addition, and the actual registering of a driver should be
done in that driver and be the same if the driver is statically or
dynamically linked.  If the driver is statically linked, there needs to be
a way to make sure that the driver initialization is done at some
approprate point early in boot.  In the dynamic case, the same
initialization is done when the module is loaded. 

  For the second condition, the code should be included by default and
only removed if explicitly requested.  However, this should only mean that
the interface code is included, not that a driver that implements it is
necessarily included.  A separate mechanism should be created to allow
kernel configuration to prohibit certain types of modules from being
loaded even if the hooks are present, so that given only a linker you can
decide if you want to statically link in a module, possibly dynamically
load it later, or prohibit that type of module from being loaded.

>   I *WANT* config files.
>   I do not want things to magically happen. That way lies Windows.

  Magical loading of modules when needed is a different issue.  I think
this should be possible, but certainly not done by default.  For some
personal users, the convenience is worth the cost.  Also, once module
signing is available you can configure in the signatures of modules you
allow, which would make autoloading a quite safe activity (though still
not desireable in all situations). 

>>   I think one requirement in any serious move towards dynamic
>> configuration should be the ability to create a statically linked kernel
>> with only object files and a linker.  As long as things like DEBUG and
>> DIAGNOSTIC are defined at compile time, it should not be that difficult to
>> do (though it would still involve a fair number of changes).  Config info
>> could be written with linker scripts.
> 
>   Please explain further.

  Instead of the current config-build sequence, you would first define
DEBUG and DIAGNOSTIC if desired (with a few other options for special
cases), then compile, config, and link.  Leaving out DEBUG there are two
sets of object files that cover most users.  Config is then updated to be
able to produce linker scripts that insert the configuration data into the
binary.  With an object set, config, and a linker, you can produce a
custom statically linked kernel.  This greatly reduces the effort and disk
space needed to make and update a custom kernel, allowing more people to
do so.  Config could also produce C code with the same data for use with
linkers that do not support the script language.  The common case would be
made easier and other options would still be possible. 

  It should be possible to control what is compiled for people tracking
current.  Also, as mentioned before, it should be possible to remove the
hooks and interfaces for specific types of modules if desired.  This can
all be done easily in a makefile.

Matthew Orgass
darkstar@pgh.net