Darren Reed wrote:
On 18/09/09 10:44 AM, James Carlson wrote:
Darren Reed wrote:
James Carlson wrote:
What kind of confusion are you expecting?
If it is an opaque type, then how does it get printed?
You have to use one of the look-up functions to convert it to a string
for printing. Zones are named, not numbered, even in the kernel.
This was a key architectural decision made by (I think) Andy Tucker back
when Kevlar was being designed. I wanted zoneids to be like UIDs, GIDs,
and other UNIX IDs -- used as small integers everywhere, and converted
to names when necessary by use of name services. Andy and the other
kernel folks disagreed, and felt that strings were better, and integers
would be allocated on the fly (non-permanently) and never used as zone
identifiers, except in performance-sensitive (and entirely internal)
contexts.
As an unsigned integer for all values, except -1, or as a signed integer?
I still think it's properly "neither." Users can't reasonably do
anything with those ephemeral numbers, so printing them (or using them
in user interfaces) would be a mistake.
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.
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.
-John
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
