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