drop snd_ from DRIVER_MODULEs...

[Ian Smith]

[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:

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.

 > > 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 :) 

 > > 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?

AU$0.02, Ian