Re: [zones-discuss] [networking-discuss] is the zoneid signed or unsigned?
> > 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
Re: [zones-discuss] [networking-discuss] is the zoneid signed or unsigned?
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 zones-discuss@opensolaris.org
Re: [zones-discuss] [networking-discuss] is the zoneid signed or unsigned?
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 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [networking-discuss] is the zoneid signed or unsigned?
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 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [networking-discuss] is the zoneid signed or unsigned?
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 ___ zones-discuss mailing list zones-discuss@opensolaris.org
