On Wed, 26 May 2010, Joakim Tjernlund wrote: > > > > So no. The glibc model is _not_ any better in practice. > > In the kernel it is since it breaks the compile. The breakage > my patch introduced is a sign of that, right? In the kernel it is _worse_, because it breaks all the years and years of code we have. The thing is, "reality" > "theory". Besides, the kernel model is a lot denser, more straightforward, and in my opinion much less likely to cause problems due to having just two clear identifiers rather than that extraneous and useless __BYTE_ORDER one. So even in theory, I don't agree. It's not like we've really had problems with our model. > hmm, so then I guess the existing use of __BYTE_ORDER in the > kernel should be removed? Yes. Except in the places where it exists solely due to user-space header exporting (and there it generally is a big hint that something is wrong anyway, as mentioned). From my quick grep (read: "not verified") there's a couple of files like that. It's probably not worth trying to change (one of them is about __BIG_ENDIAN_BITFIELD, which is due to people using bitfields for transferring data. That _is_ misdesigned. Bitfield ordering is even less well defined than byte order, and if you have to use those bitfield ordering things, it's almost always a sign that you shouldn't have used bitfields, and used explicit shifts-and-masks instead) Linus -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
