[OpenAFS-devel] Re: [OpenAFS] 2.6 kernel support anytime soon? Workarounds?

[Jeffrey Hutzelman]

On Tuesday, May 11, 2004 13:19:15 -0500 "Neulinger, Nathan" <nneul@umr.edu> 
wrote:

> I think Jeff's numbers were a bit too wide... I believe that if you
> reserve over >=32512 you should be fine.
>
> i.e. 7F00 - BF00 would be the range you want to avoid...

Hm; let's analyze this...
The magic groups are constructed as follows:

+ The PAG is a total of 31 bits
+ The low 28 bits 'l' are split into two parts:
   - (l & 0x3fff) becomes the low 14 bits of one group
   - (l >> 14)    becomes the low 14 bits of the other group.
+ The high 3 bits 'h' are split into two parts:
   - (l / 3) becomes the high 2 bits of one group
   - (l % 3) becomes the high 2 bits of the other group.
   Note that these quantities are always in the range (0..2).
+ Now, each group is in the range 0..0xBFFF.
+ Finally, we add 0x3F00 to each group, mapping them into the range
  0x3F00..0xFEFF.

These days, we start allocating PAGs at 0x41000000, and the allocation 
scheme is such that they normally wrap around at 0x41FFFFFF.  So the high 
three bits 'h' will always be 0b100 == 4, making the high two bits of each 
group always '01'.  That means the unshifted numbers are in the range 
0x4000..0x7FFF, and the shifted ones range from 0x7F00..0xBEFF, or 
32512..48895.

Note however that _any_ pair of groups (the first two groups in the 
supplementary list) in the range 0x3F00..0xFEFF will be treated as a valid 
PAG.  This may cause strange behaviour if you have users who are 
legitimately a member of more than one such group.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA