[RFC] #define __BYTE_ORDER
in [Kernel]
|
Prev: [PATCH 00/07] net: remove trailing spaces in messages
Next: [PATCH 5/7] wireless/prism54: remove trailing space in messages
From: Joakim Tjernlund on 24 Mar 2010 18:00 David Daney <ddaney(a)caviumnetworks.com> wrote on 2010/03/24 19:53:13: > > On 03/24/2010 11:37 AM, Geert Uytterhoeven wrote: > > On Wed, Mar 24, 2010 at 19:21, Andrew Morton<akpm(a)linux-foundation.org> wrote: > >> On Wed, 17 Mar 2010 19:10:55 +0100 > >> Joakim Tjernlund<Joakim.Tjernlund(a)transmode.se> wrote: > >> > >>> Linux does not define __BYTE_ORDER in its endian header files > >>> which makes some header files bend backwards to get at the > >>> current endian. Lets #define __BYTE_ORDER in big_endian.h/litte_endian.h > >>> to make it easier for header files that are used in user space too. > >> > >> I don't get it. Why not nuke __BYTE_ORDER altogether and do `#ifdef > >> __LITTLE_ENDIAN' and `#ifdef __BIG_ENDIAN' everywhere? > > > > Because in userspace the convention is that > > 1. _both_ __LITTLE_ENDIAN and __BIG_ENDIAN are defined, > > 2. you have to test for e.g. __BYTE_ORDER == __BIG_ENDIAN. > > > > I have stumbled on this issue as well. > > However, consider this: > > If you make such a change, then you will start to see: > > #if __BYTE_ORDER == __BIG_ENDIAN > > appearing in kernel source code. Do we want two different endian > checking idioms in the kernel? Or would it be just a single idiom, but > one that is different than the status quo? From my patch you already see that there some ugliness in header files because one wants to use them in user space too. I don't think inventing a kernel specific idiom will by us anything. To keep the confusion down it is better to just use #if __BYTE_ORDER == __BIG_ENDIAN all over. > > The only time I can see that it makes a difference is if you want to > share things like driver source code files between in-kernel drivers and > userspace. A discussion of which, would probably provoke much discussion. Yes, I stumbled over this when I moved crc32.c to run the test routine included in there. Took me quite a while to figure out what was wrong because you don't even get a warning, it just silently breaks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |