[PATCH] sound(4) related manpages 5.3 TODO item
cg at ijcg.net
Mon Aug 30 08:28:52 PDT 2004
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
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:
More information about the freebsd-current