From: Andi Kleen <ak@suse.de>
To: Matthew Wilcox <willy@debian.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: CONFIG_64_BIT
Date: 02 Sep 2003 19:35:11 +0200 [thread overview]
Message-ID: <p73wucrm6uo.fsf@oldwotan.suse.de> (raw)
In-Reply-To: <20030902143424.GO13467@parcelfarce.linux.theplanet.co.uk.suse.lists.linux.kernel>
Matthew Wilcox <willy@debian.org> writes:
> What do people think of CONFIG_64_BIT? It saves us from using
> !(IA64 || MIPS64 || PARISC64 || S390X || SPARC64 || X86_64) or
> the X86_64 people deciding their architecture is more important.
>
> I also considered CONFIG_ILP32 vs CONFIG_LP64 (since that's the real
> problem with, eg, megaraid), but that requires more explanation and
> offers people several ways to get it wrong (should I depend on ILP32
> or !LP64?)
At least for code BITS_PER_LONG == 64 is already good enough.
For Kconfigs it may make sense, but is there any Config rule that
checks for all 64bit archs (opposed to checking for specific archs)?
I cannot thinkg of any.
-Andi
-
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/
Matthew Wilcox <willy@debian.org> writes:
> What do people think of CONFIG_64_BIT? It saves us from using
> !(IA64 || MIPS64 || PARISC64 || S390X || SPARC64 || X86_64) or
> the X86_64 people deciding their architecture is more important.
>
> I also considered CONFIG_ILP32 vs CONFIG_LP64 (since that's the real
> problem with, eg, megaraid), but that requires more explanation and
> offers people several ways to get it wrong (should I depend on ILP32
> or !LP64?)
At least for code BITS_PER_LONG == 64 is already good enough.
For Kconfigs it may make sense, but is there any Config rule that
checks for all 64bit archs (opposed to checking for specific archs)?
I cannot thinkg of any.
-Andi
next parent reply other threads:[~2003-09-02 17:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20030902143424.GO13467@parcelfarce.linux.theplanet.co.uk.suse.lists.linux.kernel>
2003-09-02 17:35 ` Andi Kleen [this message]
2003-09-02 17:44 ` CONFIG_64_BIT Matthew Wilcox
2003-09-02 17:52 ` CONFIG_64_BIT Andi Kleen
2003-09-03 13:37 ` CONFIG_64_BIT Alan Cox
2003-09-02 14:34 CONFIG_64_BIT Matthew Wilcox
2003-09-02 17:52 ` CONFIG_64_BIT Jeff Garzik
2003-09-03 8:39 ` CONFIG_64_BIT Geert Uytterhoeven
2003-09-03 10:10 ` CONFIG_64_BIT Andreas Schwab
2003-09-03 10:44 ` CONFIG_64_BIT Wade
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=p73wucrm6uo.fsf@oldwotan.suse.de \
--to=ak@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=willy@debian.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox