From: "H. Peter Anvin" <hpa@zytor.com>
To: linux-kernel@vger.kernel.org
Subject: Re: hammer: MAP_32BIT
Date: 13 May 2003 11:54:02 -0700 [thread overview]
Message-ID: <b9rf0a$qo7$1@cesium.transmeta.com> (raw)
In-Reply-To: 1052597418.1881.2.camel@lapdancer.baythorne.internal
Followup to: <1052597418.1881.2.camel@lapdancer.baythorne.internal>
By author: David Woodhouse <dwmw2@infradead.org>
In newsgroup: linux.dev.kernel
>
> On Sat, 2003-05-10 at 02:48, Andi Kleen wrote:
> > > Oh, and please rename MAP_32BIT to MAP_31BIT. This will save nerves on
> > > all sides.
> >
> > I bet changing it will cost more nerves in supporting all these people
> > whose software doesn't compile anymore. And it's not really a lie. 2GB
> > is 32bit too.
>
> If that's _really_ an issue, then also provide MAP_32BIT which does what
> its name implies.
>
> Anyone who was using MAP_32BIT in the knowledge that it really limits to
> 31 bits gets the breakage they deserve for not reporting and fixing the
> problem at the time.
>
Agreed.
That being said, I think a more flexible scheme is called for; I still
would like to suggest the MAP_MAXADDR and MAP_MAXADDR_ADVISORY flags
that I mentioned earlier.
If people really want to retain the (rarely used) suggestion address,
I'd suggest making the address argument a pointer to a structure:
struct map_maxaddr {
void *search; /* Suggestion address */
void *min; /* Lowest acceptable address */
void *max; /* Maximum acceptable address */
};
... however, it seems like overkill to me.
-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
prev parent reply other threads:[~2003-05-13 18:42 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-09 7:35 hammer: MAP_32BIT Ulrich Drepper
2003-05-09 9:20 ` Andi Kleen
2003-05-09 11:28 ` mikpe
2003-05-09 11:38 ` Andi Kleen
2003-05-09 11:52 ` mikpe
2003-05-09 12:16 ` Andi Kleen
2003-05-09 18:11 ` H. Peter Anvin
2003-05-09 19:24 ` Ulrich Drepper
2003-05-09 20:55 ` H. Peter Anvin
2003-05-09 21:45 ` Ulrich Drepper
2003-05-09 22:07 ` H. Peter Anvin
2003-05-09 22:20 ` Ulrich Drepper
2003-05-09 22:21 ` H. Peter Anvin
2003-05-09 22:20 ` Timothy Miller
2003-05-09 22:20 ` H. Peter Anvin
2003-05-09 22:46 ` Timothy Miller
2003-05-09 23:24 ` H. Peter Anvin
2003-05-13 14:25 ` Timothy Miller
2003-05-09 22:22 ` Ulrich Drepper
2003-05-09 22:53 ` Timothy Miller
2003-05-09 23:24 ` Ulrich Drepper
2003-05-10 0:00 ` Edgar Toernig
2003-05-10 0:58 ` Ulrich Drepper
2003-05-10 2:51 ` Edgar Toernig
2003-05-09 17:36 ` H. Peter Anvin
2003-05-09 17:39 ` Ulrich Drepper
2003-05-10 1:48 ` Andi Kleen
2003-05-10 20:10 ` David Woodhouse
2003-05-13 18:54 ` H. Peter Anvin [this message]
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='b9rf0a$qo7$1@cesium.transmeta.com' \
--to=hpa@zytor.com \
--cc=linux-kernel@vger.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.