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