From: Grant Grundler <grundler@parisc-linux.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: David Miller <davem@davemloft.net>,
jaswinder@kernel.org, mingo@elte.hu, x86@kernel.org,
linux-kernel@vger.kernel.org, linux-parisc@vger.kernel.org
Subject: Re: Confusion in usr/include/asm-generic/fcntl.h
Date: Wed, 21 Jan 2009 15:25:22 -0700 [thread overview]
Message-ID: <20090121222522.GB15211@colo.lackof.org> (raw)
In-Reply-To: <200901210124.26118.arnd@arndb.de>
On Wed, Jan 21, 2009 at 01:24:25AM +0100, Arnd Bergmann wrote:
...
> > This file needs to test for 64-bit'ness using some non-CONFIG_*
> > test. And the standard built-in CPP macros which can be used
> > to check for that are different on every platform.
>
> I think we should simply define a macro for use in the kernel, e.g. in
> <asm/types.h>. There already is a BITS_PER_LONG macro in there, maybe
> we can add an exported __BITS_PER_LONG there that checks for the right
> macro on each architecture.
I'm pretty sure __LP64__ is the standard compiler defined macro
for 64-bit builds on most architectures.
> On parisc, there is a major confusion in this area, at some point, all
> checks for __LP64__ got replaced with CONFIG_64BIT there. While I have
> not understood what the problem with __LP64__ was,
IIRC, the problem with __LP64__ is it wasn't visible to the CONFIG
tool chains and dependencies. I believe that's fixed now and parisc
could deprecate use of CONFIG_64BIT if there is a strong preference
for __LP64__.
> the check for
> CONFIG_64BIT on parisc user space looks very wrong.
This shouldn't be exported to user space. Is that what you meant?
PA-RISC user space can currently only be 32-bit anyway.
So a 64-bit kernel will have to take that into consideration.
thanks,
grant
next prev parent reply other threads:[~2009-01-21 22:25 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-21 0:04 Confusion in usr/include/asm-generic/fcntl.h Jaswinder Singh Rajput
2009-01-21 0:16 ` David Miller
2009-01-21 0:24 ` Arnd Bergmann
2009-01-21 0:32 ` David Miller
2009-01-21 8:13 ` Helge Deller
2009-01-21 8:24 ` Arnd Bergmann
2009-01-21 11:38 ` Sam Ravnborg
2009-01-21 12:13 ` Arnd Bergmann
2009-01-21 12:13 ` Arnd Bergmann
2009-01-21 14:29 ` Kyle McMartin
2009-01-21 14:29 ` Kyle McMartin
2009-01-21 16:44 ` H. Peter Anvin
2009-01-21 17:28 ` Sam Ravnborg
2009-01-21 17:28 ` Sam Ravnborg
2009-01-21 17:57 ` H. Peter Anvin
2009-01-27 22:35 ` Helge Deller
2009-01-21 22:25 ` Grant Grundler [this message]
2009-01-21 22:43 ` John David Anglin
2009-01-22 0:46 ` H. Peter Anvin
2009-01-22 2:52 ` John David Anglin
2009-01-22 2:56 ` H. Peter Anvin
2009-01-21 0:48 ` H. Peter Anvin
2009-01-21 1:47 ` H. Peter Anvin
2009-01-23 15:18 ` Jaswinder Singh Rajput
2009-01-26 15:53 ` Arnd Bergmann
2009-01-26 16:24 ` Jaswinder Singh Rajput
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090121222522.GB15211@colo.lackof.org \
--to=grundler@parisc-linux.org \
--cc=arnd@arndb.de \
--cc=davem@davemloft.net \
--cc=jaswinder@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.