[PATCH] sound(4) related manpages 5.3 TODO item

[cg]

On Sun, 29 Aug 2004 23:59:42 +0300, Ruslan Ermilov <ru at FreeBSD.org> wrote:

> I wish there would be more consistency in naming.  Previously,
> we had the csa(4) manpage, "device csa", and /dev/csa* entries.
> Now we will have the snd_csa(4) manpage, "device snd_csa", but
> still /dev/csaX entry.
>
> Also, in the old world, "midi" devices were created as children
> of "pcm" devices, so "hint.pcm.0" hints for non-PnP ISA devices
> looked correct.  In new world with your updated midi(4), what
> will be the hints for the ISA device that implements PCM and
> MIDI?  hint.pcm.0 and hint.midi.0?

the intention behind the renaming was to simplify the naming scheme, and  
to glue pcm and midi together such that card drivers didn't have to  
separate out their pcm, midi and independant code.

if you look at any of the current card drivers, you'll find that they make  
several calls into the pcm code.  those supporting midi, likewise, call  
into midi code.  having midi and pcm as seperate devices gives the  
impression that they're independant, but if we allowed that to be the case  
the drivers would have to become far more complex.  ie, they each would  
require a separate module for their pcm, midi and general parts because if  
say, only midi was compiled into the kernel then the pcm code in the  
drivers would fail to link.  likewise, drivers supporting midi would fail  
to link if only pcm was present.

for modules, this problem can be solved with dependancies, but the only  
solution for a static kernel would be to declare that if you wish to  
compile a driver that supports pac and midi, both device pcm and device  
midi must be specified.

rather than leave the situation that way, we elected to combine the pcm  
and midi devices into one, so the card drivers could assume both were  
present.

renaming the card modules is a different story, and although i was in  
favour of it, i now feel it wasn't such a good idea in its current form.   
because pcm is just a framework rather than an actual device from the  
kernel's point of view, the driver name would show up in dmesg etc as  
snd_emu10k1 or whatever.  while that in itself wouldn't cause a problem,  
it would result in each driver using a different devclass - and there are  
some fairly fundamental assumptions in the pcm code that is designed  
around being able to translate a unit number to a device_t.

if the drivers were changed to register as snd_* rather than pcm, but  
remain sharing their devclass, there would be interesting results: either  
all sound devices would show up with the name of the one that attached  
first (eg an ich and emu10k1 as snd_ich0 and snd_ich1) or the unit numbers  
would be shared across devices (eg, snd_ich0, snd_maestro1, snd_cmi2...)

both of those possible outcomes would be worse than the current situation,  
in my opinion.

what we can - and should - do is rename the "pcm" devclass to "sound".   
this would make sound devices show up as sound0 etc, and make the  
hints/sysctls be hw.sound0.*.  we also need to make sure that the sound.ko  
module contains both pcm and midi.

it might be nice to have a meta device called sound_all which pulled in  
all the drivers plus the pcm and midi code, and a corresponding kld.

i wonder if we still have the opportunity to rename snd* to sound*?  or  
possibly sound to snd which would mesh better with /dev/sndstat.

> ;) All is so plain in the old good 4.x world:

heh.

	-cg