From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: linux-next: build warning in Linus'tree Date: Wed, 26 May 2010 10:45:27 -0700 (PDT) Message-ID: References: <20100526110506.f2f4f22c.sfr@canb.auug.org.au> <20100525182040.f1882d0a.akpm@linux-foundation.org> <20100526140900.5b091c16.sfr@canb.auug.org.au> <20100525234116.71889c71.akpm@linux-foundation.org> <20100526171424.447fac18.sfr@canb.auug.org.au> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-path: Received: from smtp1.linux-foundation.org ([140.211.169.13]:37572 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754822Ab0EZRsp (ORCPT ); Wed, 26 May 2010 13:48:45 -0400 In-Reply-To: Sender: linux-next-owner@vger.kernel.org List-ID: To: Joakim Tjernlund Cc: Andrew Morton , linux-kernel@vger.kernel.org, linux-next@vger.kernel.org, Stephen Rothwell 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