cvs commit: src/sys/dev/sound/pcm sound.c

[ Available lists | Index of cvs-src | Month of Mar 2006 | Week of 31 Mar 2006 | Raw email | View thread | Wrap long lines | Reply | Tag ]
From
Ariff Abdullah <ariff@FreeBSD.org>
Date
31 Mar 2006 10:36:37
Subject
cvs commit: src/sys/dev/sound/pcm sound.c
Message-ID
200603311036.k2VAaamv059069@repoman.freebsd.org


[ Hide this part ]
ariff       2006-03-31 10:36:36 UTC

FreeBSD src repository

Modified files:
sys/dev/sound/pcm sound.c
Log:
MEGA Fixes / Cleanup
--------------------

- Seal the fate of long standing memory leak (4 years, 7 months) during
pcm_unregister(). While destroying cdevs, scan / detect possible
children and free its SLIST placeholder properly.
- Optimize channel allocation / numbering even further. Do brute cyclic
checking only if the channel numbering screwed.
- Mega vchan create/destroy cleanup:
o Implement pcm_setvchans() so everybody can use it freely instead
of implementing their own, be it through sysctl or channel auto
allocation.
o Increase vchan creation/destruction resiliency:
+ it's possible to increase/decrease total vchans even during
busy playback/recording. Busy channel will be left alone, untouched.
Abusive test sample:
# play whatever...
#
while : ; do
sysctl hw.snd.pcm0.vchans=1
sysctl hw.snd.pcm0.vchans=10
sysctl hw.snd.pcm0.vchans=100
sysctl hw.snd.pcm0.vchans=200
done
# Play something else, leave above loop running frantically.
+ Seal another 4 years old bug where it is possible to destroy (virtual)
channel even when its cdevs being referenced by other process.
The "First Come First Served" nature of dsp_clone() is the main
culprit of this issue, and usually manifest itself as dangling
channel <-> process association. Ensure that all of its cdevs
are free from being referenced before destroying it (through
ORPHAN_CDEVT() macross).

All these fixes (including previous fixes) will be MFCed, later.

Revision Changes Path
1.103 +239 -300 src/sys/dev/sound/pcm/sound.c


Elapsed time: 0.086 seconds