On Monday, July 24, 2006 10:47:28 AM -0400 chas williams - CONTRACTOR
<[EMAIL PROTECTED]> wrote:
In message <[EMAIL PROTECTED]>,Jeffrey
Hutzelman w rites:
Well, actually there is still an issue. The reason PAG's are only 24
bits wide is so that we can use the remaining bits to flag a particular
value as being a PAG ID rather than a UID. Since tokens, fileserver
connections, and cached access rights can be associated with either,
they have to belong to the same namespace. We could fix this, of
course, but it will take some doing.
once we do away with using groups to encode this information, i suspect
that we would no longer need to use 8 bits to indicate that this is
an afs pag. the pag key will only contain a pag.
The 8 bits aren't about indicating that the group encoding is valid;
they're not even encoded. They're about distinguishing PAG's from UID's in
all the _other_ places where they appear.
with the current code, i suspect one would get clever and use fewer bits
to detect the afs pag groups. something like an ECC/cksum in the upper
4 bits instead of 'A' in the upper 8.
You could do that, except then how do you explain to admins which UID's
they must avoid? Right now, it's easy - avoid UID's 0x41000000-0x41FFFFFF.
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
