Seems like a good idea to me.
The only caveat here is that I think it should remain possible to access
NICs by hardware driver name, if folks so choose (i.e. configure the
vanity names by default, but allow admins who are familiar with and may
prefer the hardware names -- for whatever reason -- to do so.)
One goofy issue here is interface stability. I think part of the
problem is that we don't really know what the classification of Indiana
is for interface stability. It seems to fluctuate between a Minor and a
Major release. If its a Minor, then notification of changing names in
the release notes seems appropriate.
Perhaps one way to address the potential stability would be to submit a
possible "EOF notice" for "hardware names" indicating that the default
names of network devices in the future may change to net0... etc. (This
is really a release notes change for some future S10 update....) (That
may require Clearview be available in said S10 update, however.)
- Garrett
Peter Memishian wrote:
> Folks,
>
> As some of you may be aware, Clearview Nemo Unification and Vanity Naming
> integrated into Nevada build 83. Among other advantages, the "vanity
> naming" feature allows us to finally[1] move away from the current chipset
> alphabet soup we have for network interface names, and instead standardize
> on simple names like net0/net1. For more background, see:
>
> http://www.opensolaris.org/os/project/clearview/uv/
> http://www.opensolaris.org/os/project/clearview/uv/howto
>
> In Nevada, backward compatibility concerns have stopped us from changing
> the default naming convention, so one is still stuck with unintelligible
> names like e1000g2. However, Indiana's experimental nature seems to make
> it an ideal vehicle for making such a change, and its target userbase
> seems suited for benefitting from such a change (e.g., networking
> procedures aimed at new adoptees could simply assume the first network
> interface is net0, rather than using placeholder interface names).
>
> Thoughts?
>
> PS. Please note that device information is still available -- e.g.,
> post-build-83, "dladm show-phys" will show the underlying device
> (e.g. e1000g2) associated with each link. Ongoing work (such as
> NWAM's GUI) will likely provide detailed hardware information about
> each network interface.
>
> [1] This happened forever ago for other hardware like disks -- can one
> imagine having /dev/seagate0 and /dev/maxtor1? Yikes.
>
>
