On Fri, Mar 02, 2007 at 08:57:12PM +0800, Peter Memishian wrote: > > > The "two level" namespace could be a way out of this (prefix the link > > name with that of the zone, or perhaps just a "zone" specifier as an > > argument to link namespace manipulation tools). > > If I understand you correctly, the first would be somewhat similar to how > pathnames are handled, and I believe it's the best option if we decide to > make the names visible from the global zone.
It makes sense. > I think your second alternative is untenable, since it would mean > that a link name by itself (and thus an IP interface name by itself) > is no longer unique across the system, The meaning of a link name will always be context dependant, else how would a non-global zone be able to refer to "ip.tun0" and get to the right link? (That being "zone1/ip.tun0", or whatever naming is used to disambiguate). In fact, if the meaning of a link name is _not_ context dependant, why is there any need for the zone prefix for disambiguation? > and that would significantly impact the administrative model and > programming APIs that interact with interface or link names. Also, deciding on an approach for naming doesn't answer some of the other questions, for example whether assigning a link to a non-global zone is subtractive to the namespace of the global zone (this helps answer the question about the global zone attempting to create VLANs on a link that is assigned to a non-global zone). dme.
