drop snd_ from DRIVER_MODULEs...
John-Mark Gurney
gurney_j at resnet.uoregon.edu
Wed Apr 19 15:58:39 UTC 2006
Ian Smith wrote this message on Thu, Apr 20, 2006 at 00:44 +1000:
> [arch at freebsd.org not violated]
>
> On Wed, 19 Apr 2006, Alexander Leidinger wrote:
>
> > Quoting John-Mark Gurney <gurney_j at resnet.uoregon.edu> (from Wed, 19
> > Apr 2006 01:27:17 -0700):
> >
> > > Alexander Leidinger wrote this message on Wed, Apr 19, 2006 at 09:49 +0200:
> >
> > >> What are the benefits of this patch? Why should we commit it? What's
> > >> wrong with the current way of naming? How is this patch an improvement?
> > >>
> > >> I don't object to the patch (haven't tested it), but what are the benefits?
> > >
> > > The benifits are more consistant naming of our modules... Only three
> > > ethernet modules have if_ in front, and the rest are the raw device
> > > names.. It also means that the module names matches more closely to
> >
> > If no problem shows up (see below), this reason is good enough for me
> > to not object to such a change.
>
> Having recently struggled through getting my sbc + ess sound going on a
> Compaq 1500c on 5.4-RELEASE, I must say the snd_* naming was useful for
> me, eg:
I'm not proposing removing the names from the file names, only what
the kernel thinks is the module name...
# kldload via82c686
# kldstat -v
[...]
14 1 0xc510a000 4000 snd_via82c686.ko
Contains modules:
Id Name
227 pci/via82c686
[...]
# cat /dev/sndstat
FreeBSD Audio Driver (newpcm)
Installed devices:
pcm0: <VIA VT82C686A> at io 0xcc00 irq 5 kld via82c686 (1p/1r/0v channels duplex default)
So, the file name is the same, the only real user difference from this
change is that the cat /dev/sndstat says via82c686 instead of
snd_via82c686... This is from the PCM_KLDSTRING part of the patch, and
I only changed it to match the kernel module name, so I don't have a
preference as to if it changes or not...
also, w/o this change I couldn't of loaded the module the way I did
above, w/o the snd_ prefix... It appears that kldunload doesn't
reference the kldxref file as you can't unload by module name.. :(
> paqi# ll /boot/kernel | grep snd_
> -r-xr-xr-x 1 root wheel 16428 Feb 25 06:28 snd_ad1816.ko
> -r-xr-xr-x 1 root wheel 16811 Feb 25 06:28 snd_als4000.ko
> -r-xr-xr-x 1 root wheel 17676 Feb 25 06:28 snd_cmi.ko
> -r-xr-xr-x 1 root wheel 18378 Feb 25 06:28 snd_cs4281.ko
> -r-xr-xr-x 1 root wheel 30740 Feb 25 06:28 snd_csa.ko
> -r-xr-xr-x 1 root wheel 9694 Feb 25 06:28 snd_driver.ko
> -r-xr-xr-x 1 root wheel 45937 Feb 25 06:28 snd_ds1.ko
> -r-xr-xr-x 1 root wheel 26653 Feb 25 06:28 snd_emu10k1.ko
> -r-xr-xr-x 1 root wheel 22121 Feb 25 06:28 snd_es137x.ko
> -r-xr-xr-x 1 root wheel 21516 Feb 25 06:28 snd_ess.ko
> -r-xr-xr-x 1 root wheel 16099 Feb 25 06:28 snd_fm801.ko
> -r-xr-xr-x 1 root wheel 19474 Feb 25 06:28 snd_ich.ko
> -r-xr-xr-x 1 root wheel 25998 Feb 25 06:28 snd_maestro.ko
> -r-xr-xr-x 1 root wheel 34566 Feb 25 06:28 snd_maestro3.ko
> -r-xr-xr-x 1 root wheel 47784 Feb 25 06:28 snd_mss.ko
> -r-xr-xr-x 1 root wheel 68844 Feb 25 06:28 snd_neomagic.ko
> -r-xr-xr-x 1 root wheel 16755 Feb 25 06:28 snd_sb16.ko
> -r-xr-xr-x 1 root wheel 15754 Feb 25 06:28 snd_sb8.ko
> -r-xr-xr-x 1 root wheel 15734 Feb 25 06:28 snd_sbc.ko
> -r-xr-xr-x 1 root wheel 18834 Feb 25 06:28 snd_solo.ko
> -r-xr-xr-x 1 root wheel 18930 Feb 25 06:28 snd_t4dwave.ko
> -r-xr-xr-x 1 root wheel 25040 Feb 25 06:28 snd_uaudio.ko
> -r-xr-xr-x 1 root wheel 19303 Feb 25 06:28 snd_via8233.ko
> -r-xr-xr-x 1 root wheel 14935 Feb 25 06:28 snd_via82c686.ko
> -r-xr-xr-x 1 root wheel 18760 Feb 25 06:28 snd_vibes.ko
>
> That and using ..
>
> # snd_driver_load="YES" # load snd_*
>
> .. in /boot/loader.conf until I'd sussed out why snd_sbc didn't work by
> itself, so I knew to add ..
>
> # snd_sbc_load="YES" # now in kernel
> snd_ess_load="YES" # this fixed it .. bridge driver for ESS
>
> > > the driver that implemented by them (though this is a bit complicated
> > > w/ the fact that pcm is the real driver behind these modules and pcm
> > > isn't it's own device node)... It also makes my driver/module dependancy
> >
> > Do you suggest to make pcm it's own device node, and if you do, what
> > are the benefits/...?
>
> There is that inconsistency too, but I'm not sure that renaming the
> sound subsystem modules/drivers would help, not me anyway.
I haven't completely thought about making pcm it's own device node..
but there was recently this whole discussion about ethX naming, and
I thought it a bit funny that for ethernet we believe that it's good
to keep the names diverse, yet w/ sound we don't.. maybe this is
because it's rare for a person to have multiple sound cards, but w/
uaudio, things are changing...
> > > script do the correct thing wrt to gusc and sbc.. (The graph can be
> > > seen at: http://people.FreeBSD.org/~jmg/driver.pdf )... With out this
> > > change gusc and sbc would be their own sub-graphs not connected to
> > > anything besides their children...
> >
> > And we can't change gusc and sbc in a way to make your script work as
> > intended? I don't suggest doing this instead of your proposal, I just
> > want to know what options we have.
>
> Ditto. And I got to test 4 pdf viewers through the big graph, too :)
We can always leave it be, and have special hacks hanging around... I
just noticed some interesting inconsistancies and thought I'd bring
things together...
> > > Though I do realize that sound module names are special since they
> > > can (and do) end in numbers which none of our other drivers do...
> >
> > Is this a problem? And if yes, why is this not a problem with the
> > current snd_ prefix?
>
> They're also special because they constitute a fairly clear subsystem,
> and while taking John-Marc's point that noone needs if_ prefixes for
> ethernet drivers and such, I (and maybe POLA?) think the advantages
> of consistent snd_ naming outweigh other perceived inconsistencies.
>
> Is it also proposed to remove eg acpi_ from the ACPI subsystem modules?
No, since they are named acpi_*...
static driver_t acpi_video_driver = {
"acpi_video",
[...]
DRIVER_MODULE(acpi_video, vgapci, acpi_video_driver, acpi_video_devclass,
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
More information about the freebsd-multimedia
mailing list