From owner-freebsd-multimedia@FreeBSD.ORG Wed Apr 19 15:58:35 2006 Return-Path: X-Original-To: multimedia@freebsd.org Delivered-To: freebsd-multimedia@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1AD7216A42D for ; Wed, 19 Apr 2006 15:58:35 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E56C43D6E for ; Wed, 19 Apr 2006 15:58:22 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (ot9txvi75ldg3gl1@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.4/8.13.3) with ESMTP id k3JFwLGn079754; Wed, 19 Apr 2006 08:58:21 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.4/8.13.3/Submit) id k3JFwKk5079753; Wed, 19 Apr 2006 08:58:20 -0700 (PDT) (envelope-from jmg) Date: Wed, 19 Apr 2006 08:58:19 -0700 From: John-Mark Gurney To: Ian Smith Message-ID: <20060419155819.GK38619@funkthat.com> Mail-Followup-To: Ian Smith , Alexander Leidinger , multimedia@freebsd.org References: <20060419110126.4iz4bj0x5wo4wwgk@netchild.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: Alexander Leidinger , multimedia@freebsd.org Subject: Re: drop snd_ from DRIVER_MODULEs... X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2006 15:58:39 -0000 Ian Smith wrote this message on Thu, Apr 20, 2006 at 00:44 +1000: > [arch@freebsd.org not violated] > > On Wed, 19 Apr 2006, Alexander Leidinger wrote: > > > Quoting John-Mark Gurney (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: 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."