i'm fine with putting both firmware and plugin modules in "misc". my main concern is that the documentation provide guidance on this so it's not a free for all. if those recommendations include the use of the "misc" directory, then i agree that a modlmisc(9s) man page should be delivered as well. lastly, while i think a driver registery is a great idea, that's a seperate issue for another case. ed
On Wed, Jun 20, 2007 at 08:11:12AM -0600, Chris Horne wrote: > Hi Ed > > > but in your example below, are you delivering firmware in these > > misc modules? or are these misc modules essentially modular > > plugins for the scsi_vhci driver? (i thought they were the > > latter.) > > In the example I gave they are plugins, but putting modules > that driver xxx is going to ddi_modopen(9F) in a misc/xxx directory > helps scope the namespace in both cases (i.e. I think the advise > applies to both situations). It also makes sense for these > modules to be below "misc" because they use "misc" modlinkage(9s). > > In addition to the man pages in the original case > <http://sac.eng/PSARC/2005/050/>, this case should also introduce a > new modlmisc(9s) peer of modldrv(9s) and modlstrmod(9s) > (I missed that in the original case). > > What's missing is an registry of driver names. We have some > registry links available in the bottom of the left hand column > of <http://sac.eng/arc>, but there is nothing for driver names > (or kernel-module names). (NOTE: this could be initially > populated by extracting information from collected customer > explorer data). > > -Chris > > > this arc case was proposing that the promotion of ddi_modopen() > > and friends was for the specific purpose of loading hardware > > firmware modules, but there would be no reason that driver > > writers wouldn't be able to use these interfaces for modularization > > purposes as well, in which case it seems that the documentation > > for these interfaces should provide some module naming advice > > for both scenarios. > > > > ed > > > > On Tue, Jun 19, 2007 at 09:51:12PM -0600, Chris Horne wrote: > > > >>The reason I did not push naming in the original case > >>was because it is easy to get wrong, esp if you don't > >>have much use experience. We have some more > >>experience now. > >> > >>For driver use, my recommendation is to fix > >> > >>6504975 ddi_modopen should allow open in subdirectory > >> > >>and tell people to deliver into a directory in misc that has the same > >>name as the driver. This is what we plan to do as part of > >>opensource for mpxio/scsi_vhci. > >> > >>-Chris > >> > >># modinfo | grep scsi_vhci > >>22 13db490 1a0e8 189 1 scsi_vhci (SCSI VHCI Driver 1.65) > >>24 13f5378 1318 - 1 scsi_vhci_f_asym_sun (f_asym_sun 1.28) > >>25 13f65c0 34d8 - 1 scsi_vhci_f_asym_lsi (f_asym_lsi 1.28) > >>26 13f9860 2630 - 1 scsi_vhci_f_asym_emc (f_asym_emc 1.28) > >>27 13fbda8 3f8 - 1 scsi_vhci_f_sym_emc (f_sym_emc 1.3) > >>28 13fc0d0 588 - 1 scsi_vhci_f_sym (f_sym 1.28) > >>29 13fc510 3148 - 1 scsi_vhci_f_tpgs (f_tpgs 1.28) > >># ls -R /kernel/misc/scsi_vhci > >>/kernel/misc/scsi_vhci: > >>sparcv9 > >> > >>/kernel/misc/scsi_vhci/sparcv9: > >>scsi_vhci_f_asym_emc scsi_vhci_f_asym_sun scsi_vhci_f_sym_emc > >>scsi_vhci_f_asym_lsi scsi_vhci_f_sym scsi_vhci_f_tpgs > >># find /kernel/drv -name scsi_vhci -print > >>/kernel/drv/sparcv9/scsi_vhci > >> > >> > >> > >>>Tzongyu Paul Lee writes: > >>> > >>> > >>>>I would suggest that you take some leadership to avoid potential name > >>>>space pollution > >>>>that is hard to undo later. > >>>>The suggestion of using driver name as prefix with special _extension is > >>>>quite reasonable. > >>>>I like the idea. > >>>>We are counting on the disambiguating power of driver name, and that's a > >>>>good start. > >>>>You can recommend the use of of version/date/descriptive word to driver > >>>>writers to manage > >>>>their own name space as they see fit. > >>>> > >>> > >>>I would not suggest baking version numbers or (worse) dates into path > >>>names unless there's a _really_ good reason to do so. Merely > >>>disambiguating modules is not a "good reason." (On the other hand, if > >>>we had a magical kernel that could deal with multiple versions of the > >>>same module on the system at the same time, then that'd be a good > >>>reason.) > >>> > >>>The original 2005/050 case had a proposal for the naming scheme and, > >>>though I asked the submitter of this case about it, I'm really not > >>>clear on why this wasn't just brought forward: > >>> > >>> [<stock-symbol>_]<purpose>_<variation>[.<version>] > >>> > >>> For legacy Sun-developed plug-in 'misc' modules the stock-symbol is > >>> optional, new Sun-developed modules and third party modules should > >>> specify their stock-symbol (SUNW, etc) to avoid name conflicts. If > >>> there is only one consumer then <purpose> may be the consuming > >>> <modulename> (svm's meta disk driver (md(7D) would use "md"), > >>> otherwise a more generic name should be used to express purpose. > >>> The <variation> field describes what variation of an interface is > >>> implemented by the plug-in (the legacy "md_mirror" module > >>> implements mirroring below the "md" driver). The <version> field is > >>> optional, it might be used if programmer decides to implement > >>> by-mod-name versioning. > >>> > >>>(Personally, I'd lose the "<version>" goop here, as it only adds to > >>>the potential for disaster, but if it's only a recommendation, I'm > >>>slightly less concerned.) > >>> > >>>
