Re: Persistent module storage [was Linux 2.4 Status / TODO page]

[David Woodhouse <dwmw2@infradead.org>]

jgarzik@mandrakesoft.com said:
> > The sound card allows itself to be unloaded when the pass-through
> > mixer levels are non-zero. This is reasonable iff ...

> I don't think that is reasonable. 

You don't think that it's reasonable for the sound card to allow itself to 
be unloaded when the pass-through mixer levels are non-zero? 

So you're suggesting that we should prevent the sound drivers from being 
unloaded at all in that situation?

That would also solve the problem, at the cost of still keeping the sound 
module in unpagable RAM all the time.

jgarzik@mandrakesoft.com said:
> The first thing most drivers do is reset the hardware.   That
> inevitably leads to some sort of blip, when it comes to sound drivers.

A _momentary_ blip on certain hardware is acceptable if it's unavoidable.
Changing the levels and leaving them wrong for seconds before a user-space 
post-install script fixes them is not acceptable.

jgarzik@mandrakesoft.com said:
> You are depending on the hardware to keep its state -between- driver
> unload and driver reload.  That seems inherently unstable to me. 

No we're not. After the kerneld code was removed, I hacked up something to
do that, but it was a suboptimal solution and wasn't reliable on all
hardware. As I said, persistent storage is the better solution.

With persistent storage, the sound driver is free to reset and initialise
the sound card hardware upon reload - it's just that it can initialise it to
the levels which the user had previously set, rather than to the compiled-in
default levels (which are preferably zero). 

Initialising the levels to a default and expecting a user-space app to fix it
later is not good enough.

--
dwmw2


-
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/