Persistent module storage [was Linux 2.4 Status / TODO page]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 5 lines · Jeff Garzik
...or, give up this silly nonsense about loading and unload modules on
everyopen()andclose(). A module load modifies the running kernel
code... why do people do this on such a whim?Just load the driver at bootup and forget about it. Problem solved.
I daily curse the name of whoever added autoload and autounload. Autoload maybe useful, autounload is just asking for problems.
-
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/
Quoted 4 lines
Quoted 1 line
Just load the driver at bootup and forget about it. Problem solved.
I daily curse the name of whoever added autoload and autounload. Autoload maybe useful, autounload is just asking for problems.
Deal with it. Hardware is also now auto load and auto unloading too. For 2.5 hopefully a lot of this can be tidied up and done better - persistent storage in the modules that is written to disk and put back by insmod/rmmod (in userspace) will help a lot.
The locking issues are not going to go away. Home PC's are going more and more USB oriented. Servers are going towards more and more hotswap cards.
Alan
-
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/
Quoted 10 lines · Alan Cox
Quoted 5 lines
Quoted 2 lines
Just load the driver at bootup and forget about it. Problem solved.
I daily curse the name of whoever added autoload and autounload. Autoload maybe useful, autounload is just asking for problems.
Deal with it. Hardware is also now auto load and auto unloading too. For 2.5 hopefully a lot of this can be tidied up and done better - persistent storage in the modules that is written to disk and put back by insmod/rmmod (in userspace) will help a lot.
Not quite: plugging physically hardware in and out is compleatly different
then just loading a driver and unconditionally unloading it even when the hardware is still there!
-
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/
Quoted 4 lines
Not quite: plugging physically hardware in and out is compleatly different
then just loading a driver and unconditionally unloading it even when the hardware is still there!
Actually its no different.
Suppose I unplug my USB speakers and plug them back in again (perhaps Im just adding a hub). Do you unload and reload the driver ? If so how do you preserve the mixer levels ?
Same problem...
-
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/
Quoted 5 lines
...or, give up this silly nonsense about loading and unload modules on
everyopen()andclose(). A module load modifies the running kernel
code... why do people do this on such a whim?Just load the driver at bootup and forget about it. Problem solved.
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
-
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/
Quoted 4 lines · Alan Cox
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 unload it then - aiui most soundcards will continue passing through the TV line? right?
or another argument: how common is this case that a box with such tight memory is used in such a multi-purpose way (sometimes it uses sounds, mostly not? and even then, for such a case, is it reasonable to assume the user should deal with the memory problems? (ie it's not unreasonable to expect them to have to do extra fiddling with mixer levels).
but surely the vast majority of machines with soundcards have no good reason for unloading them?
--paulj
-
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/
Hi Alan!
Quoted 3 lines
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.
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.
Have a nice fortnight
Signature · 6 lines
Martin `MJ' Mares <[email protected]> <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/ "A mathematician is a machine for converting coffee into theorems." - 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/
Martin Mares <[email protected]> said:
[...]
Quoted 4 lines
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:
Strange somebody from a distribution forgets _the_ most important use of
modules: Remember old-time Slackware, with dozens of different boot diskettes, and the imperative to compile a kernel to your machine once you got it running?
Quoted 2 lines
o It would have to preserve _complete_ device state over module reload.
If too hard, just leave it alone: Don't allow unloading.
Quoted 2 lines
o For many drivers, the "device currently open" concept makes no sense.
Ditto.
Quoted 4 lines
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.
Ditto.
Quoted 5 lines
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.
The cases mentioned are cases where unloading (automatic or manual, doesn't matter) would break things. Just don't allow it, ever (IPv6 does this, for one example). Or fix the loading/unloading somehow. Strategies to be able to do so is what is being discussed here, BTW...
Quoted 3 lines
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,
Just force a non-zero count as long as the module is in use. Wait a minute... that is exactly what a non-zero count is supposed to mean!
Quoted 5 lines
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.
What is a "minimal ammount of memory" on the 1+Gb RAM machines I've seen discussed here isn't at all "minimal" for somebody who has to run Linux in 4Mb, preferably less...
Linux came to be what it is today in large part because the PC nobody wanted anymore ("too slow", "can't run XYZ") became the router/firewall/web server/mail server/... over in some closet, and soon nobody even remembered where the machine was physically. Don't kill this.
Signature · 7 lines
Horst von Brand [email protected] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - 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/
Hello Horst!
Quoted 4 lines
Strange somebody from a distribution forgets _the_ most important use of
modules: Remember old-time Slackware, with dozens of different boot diskettes, and the imperative to compile a kernel to your machine once you got it running?
But how is this related to automatic unloading of modules???
Even automatic loading is not needed for this purpose -- just make the startup scripts load all the modules needed and you don't have to maintain complex mappings from userspace device names to kernel drivers.
Quoted 4 lines
The cases mentioned are cases where unloading (automatic or manual, doesn't matter) would break things. Just don't allow it, ever (IPv6 does this, for one example). Or fix the loading/unloading somehow. Strategies to be able to do so is what is being discussed here, BTW...
No, the cases mentioned are cases where automatic unloading breaks things, but manual unloading is perfectly okay. Nobody expects you to preserve exact hardware state and keep things working if you unload the driver manually, but automatic unload should be perfectly transparent.
Quoted 2 lines
Just force a non-zero count as long as the module is in use. Wait a minute... that is exactly what a non-zero count is supposed to mean!
Yes, but define "in use". Does your "in use" mean "referenced by user space or by other drivers" (== cannot be unloaded without crashing the system) or "unloading this module makes something cease to work"? Currently, the use counts maintained by the drivers correspond to the first definition which is the right definition when it comes to manual unloading, but it gives you no clue when it comes to transparent automatic unloading.
Quoted 8 lines
What is a "minimal ammount of memory" on the 1+Gb RAM machines I've seen discussed here isn't at all "minimal" for somebody who has to run Linux in 4Mb, preferably less...
Linux came to be what it is today in large part because the PC nobody wanted anymore ("too slow", "can't run XYZ") became the router/firewall/web server/mail server/... over in some closet, and soon nobody even remembered where the machine was physically. Don't kill this.
In routers dreaming the ancient dreams from the elder days of their creation, you need all the modules loaded all the time anyway, hence automatic unloading doesn't apply. Even better use a monolithic kernel since it saves in average half a page per driver. (Yes, I know that current distributions don't ship with precompiled kernels suiting your machine, but current distributions don't run on a 4MB 386 anyway.)
Also, I'm not advocating killing compatibility with such old hardware (which I frequently use), but I'd very much like to avoid hacking all the drivers just to support correctly some (although sometimes useful) ill defined feature.
Have a nice fortnight
Signature · 6 lines
Martin `MJ' Mares <[email protected]> <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/ "ADA -- A Dumb Acronym" - 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/
Quoted 12 lines · Martin Mares
Hi Alan!
Quoted 3 lines
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.
Quoted 4 lines
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.
Quoted 14 lines
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.
Quoted 4 lines
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.
Quoted 5 lines
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.
Quoted 7 lines
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/
Quoted 6 lines
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
Then you APM bios is not to specification. Don't inflict your bios bugs on everyone but forcing policy.
-
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/