I've had a bit of time on my hands in the last few days, and gave
sound/oss/trident.c a much needed cleanup. The changes are mostly
cleanups, a few bug fixes where we wouldn't do cleanup properly on
error paths, and the removal of lock_kernel()/unlock_kernel().

If anyone who has this sound card wishes to take the driver for a
spin, I'd love bug/success reports. Especially on SMP and/or machines
with multiple trident cards. Andrew, if you feel it's appropriate for
-mm, please include it. 

The patch against 2.6.0 is rather large. 140kb unzipped, 30kb
gzipped. It's available at
http://www.mulix.org/patches/trident-cleanup-B1-2.6.0.diff (gzipped:
http://www.mulix.org/patches/trident-cleanup-B1-2.6.0.diff.gz)

Summary of changes: 

- run the code through Lindent, and then fix it manually (this is the
bulk of the patch) 
- switch lock_set_fmt() and unlock_set_fmt() from macros to inline
functions. Macros that call return() are EVIL. 
- simplify lock_set_fmt() and implement it via test_and_set_bit(). 
- fix a bug wherein we would do an up() on a semaphore that hasn't
been down()ed if a signal happened after timeout in trident_write()
- fix a bug where we would not release the open_sem on OOM
- make the arguments for prog_dmabuf clearer (int -> enum) 
- fix a bug where we would call VALIDATE_STATE after
lock_kernel(). Since VALIDATE_STATE does 'return' if validation fails,
bad things can happen. Thanks to Dawson Engler <engler@stanford.edu>
and the Stanford checker for spotting.
- remove the calls to lock_kernel() from trident_release() and
trident_mmap(). trident_release() appears to be covered by the
open_sem, and trident_mmap() is covered by state->sem. 
- s/TRUE/1/, s/FALSE/0/

Cheers, 
Muli 
-- 
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/

"the nucleus of linux oscillates my world" - gccbot@#offtopic