Re: Please read if you use x86 -current

["Michal Suchanek" <hramrach%centrum.cz@localhost>]

2008/11/13 Greg A. Woods; Planix, Inc. <woods%planix.ca@localhost>:
>
> On 13-Nov-2008, at 4:35 AM, Andrew Doran wrote:
>>
>> The mount command already autoloads file system modules. There is no
>> automatic unload.
>
> Why no automatic unload?  This is effectively a memory leak, though of
> course it's not one that will tend to grow uncontrollably, but still it's
> like forgetting to free memory the program no longer needs.
>
> In fact when you say things like this I really have to wonder what the whole
> point, or rather what all the reasons are, for doing this particular
> implementation you've embarked upon are.  When you say things like this it
> makes it sound as though it's just an academic exercise with no real
> attention being paid to real-world and operational concerns.  I'm not saying
> that this is the case, but there seem to have been enough questions by
> various people which result in answers like this to at least give the easy
> possibility of it being perceived as so.
>
> So, what are the actual design goals and parameters of this project?  If
> it's so simple as "GENERIC is too big and bloated again" then why are you
> barging ahead with an implementation which may not actually meet all the
> real-world requirements others might have of a similar feature?
>
> Sorry if I'm going only by what I've read in this thread an the "kmods"
> thread and reaching the wrong conclusions -- but I haven't yet seen any
> direct reference to a more detailed design or specification or requirements
> analysis, etc.

Generally there are several uses for loadable kernel modules:

 - loadable drivers can improve hardware support
    - it is possible to build a GEENRIC kernel that supports large
range of hardware while not wasting memory on drivers that are not
present in the system (and were not and will never be)
    - development of driver is easier if you do not have to reboot
every time you modify the driver. It is possible to make some
parameters tunable at runtime but if you have to change some logic the
possibility to unload and reload helps a lot
    - this applies to other features that are not used on every system
but should be included in a distribution kernel so that people can use
them

- some sort of module autoloading is a good idea. However, Linux had
autoloading and they dropped the feature in favour of semi-automatic
loading. That is, a userland process attaches somewhere to the kernel
and the kernel tells it what feature is requested but missing (PCI/USB
id of device to which no driver has bound so far, device major and
minor of a block device opened but not present, filesystem type
mounted, some special ID for something like POSIX semaphores when the
first one is cerated). There is a service running that tries to look
up a module which provides the feature or returns a failure if the
module is not found or its loading is disabled by the user.
People who do not trust autoloading may build a monolithic kernel or
disable the service but still have the option to load modules
manually. The service can be replaced by a simple script that just
tries to load all modules, too.

To have reliable driver loading form userspace either the userspace
support program has to load the drivers actively (ie load everything
it can, and drivers that do not attach just fail to load) or there has
to be a facility in the kernel that allows enumerating features that
are requested but still not provided when such service starts (this
will be typically devices to which no driver attached so far but there
might be other uses).

- automatic module unloading can be done by cron, no need to have
kernel support for that

- implementing modules that can be compiled either dynamically
loadable or statically linked does not put any burden on people who
customize their kernels and are satisfied with the current state - the
functionality still can be still included in a statically linked
kernel

Loadable kernel modules are nothing new and the benefits are well
known. If you have a real-world requirement that is not covered by
current proposal why don't you explicitly state it?

Thanks

Michal