In reviewing the current interfaces made available from zones, it appears that ALL_ZONES and GLOBAL_ZONE are still private interfaces - correct?
If so, if I'm forced 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? 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? 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. 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. Comments? Darren _______________________________________________ zones-discuss mailing list email@example.com