> > I'm not buying this logical boundary definition if you don't do clean > > cut you still have to be endian aware across the whole code so what's > > a difference. > > No, you only have to be endian aware when you do a load from a structure > you *know* was/is DMAed from/to the card. That's a world of a > difference. I'm not only loading the structure I'm using it all over the code. I don't have clean cut. You can blame me for that but that's another discussion. > > b = le_to_cpu(a) > > b != FLAG > > a = cpu_to_le(b) > > is probably longer then > > a |= FL:AG_LE; > > n matter what. > > Obviously, with a flag this is true. But if you see my example below > then you'll realise that most of the time you don't just do a single > flag in a but multiple multi-bit values. > We are going around the same issue all gain. I already agreed that your approach will be correct if we had more code of your example type then setting bits. But we are mostly setting bits. > Not considering single bits, you will have fewer swap operations as I've > shown in my example code. And you're only hiding the fact that you have > many more logical swap operations, most of which are of course constant, > when you do consider single bits. > Again we have mostly bit setting. > There's nothing you can fix here. It's not an exemption of your > approach, it's a logical consequence of your approach. Making exemptions > for things like this in your approach will imho most likely make the > code even worse. But I'm interested to see how you want to "fix" this > without going to CPU-defined constants instead of LE-defined constants. _POS are (shift constants) are native defined. > And once you start *mixing* the two approaches things will *really* be > confusing, so you really do need to write it the way I wrote (almost > quoted but simplified). Yes, something like that. > This is really arguing about taste and feel. I don't find it more confusing then any mixture of native and some-endian platform. I don't know how to measure it but I didn't see any endianity bug for more then 6 months so I guess my approach is working. In addition it all may change as we cleanup the code. Tomas - 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
