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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
