linux-kernel - Re: linux-next: build warning in Linus'tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.1005261036550.3689@i5.linux-foundation.org>
Date:	Wed, 26 May 2010 10:45:27 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Joakim Tjernlund <joakim.tjernlund@...nsmode.se>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-next@...r.kernel.org,
	Stephen Rothwell <sfr@...b.auug.org.au>
Subject: Re: linux-next: build warning in Linus'tree

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/