Re: Persistent module storage [was Linux 2.4 Status / TODO page]

[Martin Dalecki <dalecki@evision-ventures.com>]

Martin Mares wrote:
> 
> Hi Alan!
> 
> > If the sound card is only used some of the time or setup and then used
> > for TV its nice to get the 60K + 128K DMA buffer back when you dont need it
> > especially on a low end box
> 
> So why don't we allocate / free the DMA buffer on device open / close instead
> of module insert / remove?  If the reason lies in problems with allocation
> of large chunks of contiguous memory, we're going to have exactly the same
> problems when autoloading the module.
> 
> I think that automatic loading / unloading of modules has been a terrible hack
> since its first days (although back in these times a useful one) and that the
> era of its usefulness is over. There are zillions of problems with this
> mechanism, the most important ones being:

Amen.

>    o  It would have to preserve _complete_ device state over module reload.
>       For the sound card mixer settings discussed it's close to trivial, but
>       for example consider a tape drive and the problem of preserving tape
>       position after reload (probably including device reset causing tape rewind).
>       And what about textures loaded to memory of a 3D video card?
> 
>    o  For many drivers, the "device currently open" concept makes no sense.
>       Consider a mouse driver whose only activity is to feed mouse events
>       to an event device. The mouse driver can be unloaded in any time (either
>       manually or perhaps automatically after the mouse gets unplugged), hence
>       it should have a use count == zero, but even if it seems to be unused,
>       it must not be unloaded just because of some timeout since the mouse
>       will cease to work.
> 
>    o  It interferes with hotplug in nasty ways. Let's have a USB host controller
>       driver with currently no devices on its bus. It's also an example of a zero
>       use count driver, but it also must not be unloaded as it's needed for
>       recognizing newly plugged in devices.

Plese add power-saving devices like in notebooks to the list as well.
For example in my notebook the PC speaker loops through the maestro-3e.
The BIOS is initializing the maestro with some sane mixer values but
after
a suspend cycle the pc speaker is compleatly off due to suspension of
the
maestro-3e chip and the leak of a *permanent* driver sitting around to
handle
the wakeup event.

> I don't argue whether we need or need not some kind of persistent storage for
> the modules (it might be a good idea when it comes to hotplug, but it should
> be probably taken care of by the userspace hotplug helpers), but I think that
> it has no chance to solve the problems with automatic unloading.
> 
> We could of course attempt to circumvent the problems listed above by adding
> some hints to module state which will say whether it's possible to auto-unload
> the module or not even if it has zero use count, but it means another thing
> to handle in all the drivers (well, at least another thing to think of whether
> it's needed or not for each driver) and I think that the total effect of
> the autounloading mechanism (a minimum amount of memory saved) in no way
> outweighs the cost of implementing it right.

And the pain for the user of the whole: Take the example of ALSA
over-modularisation...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/