Messages in this thread |  | | From | "James A. Sutherland" <> | Subject | Re: Persistent module storage [was Linux 2.4 Status / TODO page] | Date | Tue, 7 Nov 2000 00:23:06 +0000 |
| |
On Mon, 06 Nov 2000, Evan Jeffrey wrote: > > On Mon, 06 Nov 2000, David Woodhouse wrote: > > > > > > No. You have to reset the hardware fully each time you load the module. > > > Although you _expect_ it to be in the state in which you left it, you can't > > > > > be sure of that. > > > > If a reset is needed, I think it should come explicitly from userspace. > > Take Alan's example of a USB device, say USB audio. If it is disconnected > and reconnected to add a hub, or anything else, the device may shut itself > down, go to an undefined state, or even power cycle (if it draws power from > the USB +5V). Same with hot-swap PCI cards. The driver *MUST* reset the > device on load. If saving mixer levels through this kind of transition is > desired (which it evidentally is), the module load/unload code must save and > restore the settings.
I'm not convinced.
> This is exactly equivelent to reseting hardware after a warm boot.
Interesting. If that were done, my last sound card wouldn't have worked at all under Linux: it had to be initialised under DOS before loading Linux. Had Linux then reset everything, I'd have been soundless!
> Who knows > what the Windows driver did to your card in the mean time.
Either it initialises it (as it does, in this case), and I want (even NEED) it to STAY initialised (i.e. if your driver does an unnecessary reset, your driver is broken), or it doesn't, and I'll reset the card with an ioctl.
> A device driver > can only guarantee that nobody horkes with its hardware while it is loaded-- > In the interim, the driver may have been connected to another computer, > accessed by another driver, or accessed from userspace (say, VMWare doing > a pass through driver).
So provide the FACILITY to reset the card, IFF it is needed. There are cases where resetting the card is just stupid: don't force stupidity by design into the kernel.
> I personally like the idea of having insmod/rmmod do copy-out/copy-in from > a cache file in userspace. That way, if we need large data sets (a ROM > image for something.) they don't take up kernel space when not in use. > Also, it allows people to have persistant settings across reboot through > the same mechanism--avoiding duplicating information in shutdown/startup > scripts.
I prefer the idea of the drivers which need this coming with a suitable interface (/dev or /proc item) and a script to do this when needed.
James. - 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/
|  |