On Monday 10 December 2007 16:18:57 Johannes Berg wrote: > > > > I never said you should keep native layout structures. I merely said > > > that it leads to better code if the data is converted to CPU endianness > > > at the system boundary. While the actual system boundary is obviously > > > the PCI(-E) bus, the logical system boundary may well be at the point > > > where you load a certain value from the DMA memory into the CPU to > > > operate with it (whether it's then pushed back out to memory on the > > > stack is uninteresting). > > > > 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 agree that it's a lot easier to read and maintain, if you convert _all_ your data structures (also single integers) to and from device endianness at the time when you write/read them to the device. It unifies the workflow a lot and results in much less swappings. my_data = read_drom_device() swap_to_cpu(my_data) do_whatever(my_data) store the data somewhere else in the device structs for later use, maybe. do_something_else(my_data) You see that now you have only _one_ place that you have to care about. And if you have to write your data back at some point, simply do it just before the write. And, little endian intel guys, this will simplify your life a lot by removing lots of cpu_to_xxx stuff _and_ result in no performance loss, as the swap will be optimized away. :) That's a deal, eh? And we big endian people, we don't care about one or two swap instructions. It won't hurt performance in any way. (Johannes also showed that in most cases this approach doesn't even add extra instructions). -- 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
