Re: [zones-discuss] [networking-discuss] is the zoneid signed or unsigned?

2009-09-18 Thread James Carlson
Darren Reed wrote:
 Guys, In most parts of the source code, the zoneid is unsigned,
 except for where we use ALL_ZONES. Then in some places,
 we assign or expect -1 to be the zoneid, for example in what
 psh prints and expects to see.
 
 It would seem that we want the zoneid to be unsigned except
 for when its value is -1. This seems... like it could lead to
 confusion or other bad things.

It looks to me like it's neither signed nor unsigned, but rather an
opaque type.  It supports only equality tests, not general arithmetic
ones, so signedness doesn't seem to come into it.

What kind of confusion are you expecting?

-- 
James Carlson 42.703N 71.076W carls...@workingcode.com
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] [networking-discuss] is the zoneid signed or unsigned?

2009-09-18 Thread James Carlson
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.

-- 
James Carlson 42.703N 71.076W carls...@workingcode.com
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] [networking-discuss] is the zoneid signed or unsigned?

2009-09-18 Thread James Carlson
Darren Reed wrote:
 On 18/09/09 10:44 AM, James Carlson wrote:
 Darren Reed wrote:
 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.

My argument wasn't that there were zero bugs in the OS.  That keyword
seems to me to be pretty clearly a defect in snoop.  (And apparently a
recent one; less than a year old.)

It was that the zone IDs are inherently ephemeral, and were designed to
be that way.  They're not intended as any sort of administrative
interface.  The kernel assigns them arbitrarily as the zones are
booting, and there's no guarantee at all that any particular number
represents any zone over time.  At best, they're useful in undocumented
or volatile debug interfaces (such as in mdb).

It's the zone names that are fixed and are intended as administrative
interfaces.

And that since you can't do any reasonable arithmetic comparisons
between them (what does it mean for one zone ID to be less than
another?), it doesn't really matter what a zoneid_t is inside.

-- 
James Carlson 42.703N 71.076W carls...@workingcode.com
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] [networking-discuss] is the zoneid signed or unsigned?

2009-09-18 Thread James Carlson
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 carls...@workingcode.com
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] [networking-discuss] is the zoneid signed or unsigned?

2009-09-18 Thread Peter Memishian

   Do a man snoop and search for the word zone.
  
  My argument wasn't that there were zero bugs in the OS.  That keyword
  seems to me to be pretty clearly a defect in snoop.  (And apparently a
  recent one; less than a year old.)

... and indeed, there's a CR open to allow snoop to accept zone names.

--
meem
___
zones-discuss mailing list
zones-discuss@opensolaris.org