Darren Reed writes: > In reviewing the current interfaces made available from > zones, it appears that ALL_ZONES and GLOBAL_ZONE > are still private interfaces - correct?
They're not currently documented, but given that there are public interfaces that provide access to the zoneid_t integers and that these values are constant, I doubt that, if needed, there's a serious issue involved in making them public. > If so, if I'm forced Forced? All of this is changeable. We stopped using stone tablets in the ARC years ago. ;-} > to expose the existance of zones > through an API to kernel consumers and then somehow > map zone names into zoneid_t's. While userspace has > a getzoneidbyname(), there appears to be no equivalent > in the kernel - using zone_find_by_name() appears to > be the only way. Is that a project private interface or > a consolidation private interface? As best I can tell, zone_find_by_name is just dead code. Based on the way it's defined, though, it looks like it was intended as Consolidation Private. > It would appear that the current state of the zones > interfaces requires cooperation between a program > in user space that maps a zone name to a zoneid_t > and then passes the zoneid_t into the kernel, correct? No. The existing users of the zones interfaces just uniformly found it easier to deal with small integers than with strings. You should probably design your interfaces according to your needs. > But doing this begats the original problem - there > would seem to be no correct way of specifying "all > zones" in the zoneid_t if ALL_ZONES is also private. So, make it public as part of your project. That doesn't sound like a problem. > What I'd like to do is offer an API to consumers in which > they can specify a zone by virtue of its name and resolve > that internally inside the kernel. In such a design, I might > choose to make a NULL name a wildcard, whilst allowing > the API to also be specific to the global zone or other > local zones. Thus I'd prefer to avoid exposing zoneid_t's > to the consumers completely, if I can. I'm really not fond of the idea of making NULL equivalent to a wildcard. It's far too likely to be an error case. If we need a wildcard for a zone name, then let's reserve one. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org
