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

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Reply via email to