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

> 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

Reply via email to