Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751876Ab2EREFs (ORCPT ); Fri, 18 May 2012 00:05:48 -0400 Received: from mail-wi0-f172.google.com ([209.85.212.172]:35761 "EHLO mail-wi0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750799Ab2EREFq (ORCPT ); Fri, 18 May 2012 00:05:46 -0400 MIME-Version: 1.0 In-Reply-To: References: <1337292816-10839-1-git-send-email-hjl.tools@gmail.com> <1337292816-10839-9-git-send-email-hjl.tools@gmail.com> <4FB58EFD.7010302@zytor.com> <4FB5C050.9070805@kernel.org> <4FB5C843.9070002@kernel.org> From: Linus Torvalds Date: Thu, 17 May 2012 21:05:24 -0700 X-Google-Sender-Auth: 3RCEalDsbdXx3Me5DXo8JQBlk4Q Message-ID: Subject: Re: [PATCH 08/10] Use __kernel_ulong_t in struct msqid64_ds To: "H.J. Lu" Cc: "H. Peter Anvin" , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, mingo@kernel.org, tglx@linutronix.de, Paul Mundt , David Howells Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1431 Lines: 34 On Thu, May 17, 2012 at 8:59 PM, H.J. Lu wrote: > > But __BITS_PER_LONG used in kernel header files really > means "long" as seen by kernel, not by user space. No, hjl, no it does NOT. That might be what we'd all *wish* it did, but it's not at all what it does. What it actually means is "how many bits in a long as it is being compiled right now". User code headers have absolutely *no* idea what the size "long" the kernel was compiled with. You'd have to do an "uname()" system call to figure that out, and even then you shouldn't be sure if the kernel is just really good at compatibility mode. Just look at the code. It literally sets __BITS_PER_LONG depending on *compiler* flags like __s390x__ etc. Which depend on things like "-m32" etc as done in user space. When those same headers are compiled *as*part*of*the*kernel*, then - and only then - does __BITS_PER_LONG hopefully match what the kernel "long" is. But that is kind of irrelevant, because if this was purely a kernel issue, we would use the non-underscore version (ie just "BITS_PER_LONG") which is *only* for the kernel, and not exported to user space at all. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/