John Leser wrote:
> Darren Reed wrote:
>> Do a "man snoop" and search for the word "zone".
> Oh, that was a bit of a let-down...
> Anyway, this seems to pose an interesting challenge to programs like
> snoop that want to encode zone ID information in output files.  The zone
> ID numbers are essentially meaningless in a disk file - who knows what
> zone names they corresponded to at the time the capture was done.  To be
> at all correct, IPNET headers have to encode the string literal for the
> zone name.   Ugly.

Not necessarily ... it's ok if IPNET headers have zone IDs in them, as
long as all the tools that use them translate to and from string format
when interacting with the user or transporting them externally (as in
over a network or via a file).  (I think you're right, though, that
"ideally" the interface between kernel and user space should deal with
strings, because there's no guarantee that a given zone ID that you see
in an IPNET header will necessarily correspond to the named zone you get
moments later with getzonenamebyid() -- because the ID might have been
discarded by the kernel between those two events.)

Yes, it does mean that some file formats are going to be a little less
pretty than others.

> Also, zone IDs are more ephemeral than UIDs or GIDs, because if I log
> out and back in, I keep the same UID.   If I halt and boot the same
> zone, it gets a new zone ID each time.

Exactly.  It's a different design.  As I said before, when I was working
on the old Kevlar team, I wanted a UID-like experience for these,
because I _assumed_ that people would want to administer zone names
centrally across many machines, and because it seemed to me that
integers would be easier to encode and work with.  The rest of the team,
though, assumed differently: that if there was any coordination between
machines, it would be on the basis of the assigned zone name, and that
strings were just as easy to use.

James Carlson         42.703N 71.076W         <>
zones-discuss mailing list

Reply via email to