Jonathan Adams wrote:
On Fri, May 08, 2009 at 12:15:15PM -0400, James Carlson wrote:
Garrett D'Amore writes:
James Carlson wrote:
Ick. Sure sounds like we need a better answer for that one.
Its actually not that bad. The audio framework does this on behalf of
the drivers:
The "ick" part is that it doesn't unload, which makes patching require
a reboot.
How's that? Won't patching do a targeted unload, which will succeed?
A better answer would be to find a common place where we can store
parameters, so that the driver can pick them back up later when it
reloads. Sort of like the Brussels stuff done for networking.
That's probably true. Though for audio devices, there's also the issue of
audio output (clicks and pops) when the driver attaches (which might be
driver bugs, I guess.)
Not really. The clicks and pops come from power being applied to
amplifiers, and there's not much you can do about it.
I've found the above approach works well enough that I haven't worried
about it. The only detriments are:
1) modules losing their settings when a targetted unload occurs --
I've argued that if someone is manually unloading a module, then this is
appropriate.
2) small amount of memory wasted for the driver if it isn't used.
Although most people who have an audio device have at least some use of
it -- desktop sounds, the web browser via flash, etc... so this is
really not a significant issue, IMO.
- Garrett
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
