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?
--
Greetings, Michael.
--
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
