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
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
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
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
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
