On Thu, Apr 16, 2009 at 10:48 PM, David Young <dyoung@xxxxxxxxx> wrote:
> On Thu, Apr 16, 2009 at 09:10:04PM +0200, Michael Buesch wrote:
>> On Thursday 16 April 2009 20:59:34 Johannes Berg wrote:
>> > On Thu, 2009-04-16 at 20:47 +0200, G?bor Stefanik wrote:
>> >
>> > > Alternatively, the meanings of the {0,0} and {1,1} cases could be
>> > > switched around (making the {0,0} case more logical, at the expense of
>> > > the {1,1} one):
>> > >
>> > > TX Flags absent: Use RTS & CTS as needed.
>> > > TX Flags present: {
>> > > RTS=0, CTS=0: Use RTS & CTS as needed.
>> > > RTS=0, CTS=1: Use CTS-to-self.
>> > > RTS=1, CTS=0: Use RTS/CTS-handshake.
>> > > RTS=1, CTS=1: Use neither RTS nor CTS.
>>
>> The first and the last thing let my head explode, because it's not
>> what somebody would expect from such bits. This kind of logic is also
>> used in wext. And it's why I hate wext. "bit0 means x, bit1 means y,
>> buuuuuuuuuuuuuuuut iff both bits are set the whole logic is inverted
>> and whatever..." That complicates _every_ single test of the bit
>> (always need if (bit0 is set but not bit1)) It produces spaghetti code
>> interpreting these bits with lots of branches and special conditions
>> that nobody does understand by reading the code alone. If you can't
>> encode your functionality into a boolean, do _NOT_ use bits to encode
>> it. Use integers to encode tristate or quadstate or whatever. You
>> essentially _did_ that already, if you look at your bits. You use the
>> two individual bits as 2bit integer value. So why not spell it out and
>> use an integer field for that information?
>
> G?bor,
>
> 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).
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.
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
