Re: use of radiotap bit 14?

Johannes Berg <[email protected]> Wed, 12 Dec 2007 00:09:36 +0100
Newsgroups	org.netbsd.radiotap
Message-ID	<[email protected]>
David,

> I propose to add two new presence bits, 29 and 30.  Let them both reset
> the bitmap index to 0.  That is, the bits in following next 32-bit
> presence word are interpreted as bits in 0..31, not n..31+n.  We must
> use both of these bits in conjunction with the extension bit, bit 31,
> or else they will have no effect.

The more I think about your proposal the more sense does it make :)

One thing occurred to me: this extension with bit 31 is interesting in
that it leads to holes in the numbering because number 63 can never be
assigned (it corresponds to 31 in the second bitmap). Similar things
will happen when 29/30 are reserved.

Since we haven't yet assigned anything above 23, maybe we should reserve
the flag bits 24..31 for global bits so future extensions like the
global bits 29/30 you defined could be done? As you certainly noticed
when defining the bits 29/30, this is perfectly compatible with current
parsers because they have to stop parsing at unknown bits anyway. This
would allow also allow us to declare that the bits in the second bitmap
start being numbered from 24 rather than 32 (because it doesn't matter
if existing parsers think it's an unknown bit 32 when it really is the
unknown bit 24). Of course the remaining 5 bits 24..28 would have to be
reserved and set zero, parsers would have to stop parsing when
encountering any of them set they cannot handle.

Basically this would lead to the following layout:

| n0..23 (24 bits) | g0..7 (8 bits) | n24..47 (24 bits) | g0..7 (8 bits) | ...

rather than

| 0..28 (29 bits) | 29..31 (3 bits) | | 32..60 (29 bits) | 29..31 (3 bits) | ...

where n/g indicate that they're in the numbering/global space.

I'm only proposing to do the split as 24/8 because it seems more natural
to have a whole byte reserved in the upper part although it is likely
we'll never need the extra five global bits.

johannes
signature.asc (application/pgp-signature, 828 B)