On Fri, 2009-04-17 at 03:24 +0200, Gábor Stefanik wrote: > > I see the point that Michael is making. What do you think? Shall > > we treat it as a 2-bit wide unsigned integer field in the Tx flags, > > instead? > > > > IMO that is a good idea, if we accept having non-booleans in a flags > field. In that case, this proposal comes to my mind: > -Define the second and third bits (mask 0x0006) as a quad-state flag > indicating the use of RTS/CTS. So, we can have these values for the > flag (accessible as (TXFlags & 0x0006) >> 1): > 0: neither > 1: rts > 2: cts > 3: auto-select (only makes sense when sending & during feature discovery). Like I said -- this doesn't help for feature discovery because there you may need to say "only 0 and 2 are valid values", or maybe "only 3 is a valid value". I also don't like _setting_ bits for automatic -- I have a nagging feeling that leaving out the entire field should be more similar to setting it to all-zero, rather than all-ones. It cannot ever be exactly the same for most fields, but still... > Also, a proposal for feature discovery: > The userspace can send a packet that consists of nothing but a > "christmas tree" radiotap header, with no payload, but with all fields > and flags set that are known by the userspace app. The response could > be another payloadless radiotap header, copying the bits set by > userspace, but unsetting the ones not supported by the hardware. This > way, the response packet has all flags set that are supported by both > the sender and the userspace app. Let's keep that out of this thread -- but let me note that this has no advantages (and a disadvantage in complicating the API and requiring parsing) over unilaterally sending those bits supported by the driver -- after all the app could do it the other way and unset whatever it cannot support in the full bitmap the driver gave it. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
