[lkml]   [2000]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Persistent module storage [was Linux 2.4 Status / TODO page]
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:


> 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
a suspend cycle the pc speaker is compleatly off due to suspension of
maestro-3e chip and the leak of a *permanent* driver sitting around to
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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:45    [W:0.029 / U:2.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site