Date: Mon, 30 Aug 2004 16:28:52 +0100 From: cg <cg@ijcg.net> To: "Ruslan Ermilov" <ru@freebsd.org>, "Mathew Kanner" <mat@cnd.mcgill.ca> Cc: current@freebsd.org Subject: Re: [PATCH] sound(4) related manpages 5.3 TODO item Message-ID: <opsdjxaeq397cmaj@tacitblue3.rings> In-Reply-To: <20040829205942.GC39813@ip.net.ua> References: <20040828142503.GA52613@ip.net.ua> <20040829190833.GA9796@cnd.mcgill.ca> <20040829205942.GC39813@ip.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 29 Aug 2004 23:59:42 +0300, Ruslan Ermilov <ru@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?opsdjxaeq397cmaj>