From: "H. Peter Anvin" <hpa@zytor.com>
To: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] i386 uaccess to fixmap pages
Date: 9 May 2003 20:26:40 -0700 [thread overview]
Message-ID: <b9hrhg$5v7$1@cesium.transmeta.com> (raw)
In-Reply-To: Pine.LNX.4.44.0305090856500.9705-100000@home.transmeta.com
Followup to: <Pine.LNX.4.44.0305090856500.9705-100000@home.transmeta.com>
By author: Linus Torvalds <torvalds@transmeta.com>
In newsgroup: linux.dev.kernel
>
> It actually does have some cost in that form, namely the fact that the
> kernel 1:1 mapping needs to be 4MB-aligned in order to take advantage of
> large-pte support. So we'd have to move the kernel to something like
> 0xc0400000 (and preferably higher, to make sure there is a nice hole in
> between - say 0xc1000000), which in turn has a cost of verifying that
> nothing assumes the current lay-out (we've had the 1/2/3GB TASK_SIZE
> patches floating around, but they've never had "odd sizes").
>
> There's another cost, which is that right now we share the pgd with the
> kernel fixmaps, and this would mean that we'd have a new one. That's just
> a single page, though.
>
> But it might "just work", and it would be interesting to see what the
> patch would look like. Hint hint.
>
Another option would be to put it in the "user" part of the address
space at 0xbffff000 (and move the %esp base value.) That would have
the nice side benefit that stuff like UML or whatever who wanted to
map something over the vsyscall could do so. Downside: each process
needs a PTE for this.
-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
next prev parent reply other threads:[~2003-05-10 3:14 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-09 2:03 [PATCH] i386 uaccess to fixmap pages Roland McGrath
2003-05-09 4:31 ` Andrew Morton
2003-05-09 8:55 ` Roland McGrath
2003-05-09 9:19 ` Andrew Morton
2003-05-09 9:40 ` Roland McGrath
2003-05-09 10:43 ` Roland McGrath
2003-05-09 11:42 ` Dave Jones
2003-05-09 11:55 ` Alan Cox
2003-05-09 12:40 ` Jamie Lokier
2003-05-09 16:06 ` Linus Torvalds
2003-05-09 16:38 ` Dave Hansen
2003-05-09 15:55 ` Martin J. Bligh
2003-05-09 18:20 ` William Lee Irwin III
2003-05-09 16:48 ` Linus Torvalds
2003-05-09 17:16 ` Dave Hansen
2003-05-10 3:26 ` H. Peter Anvin [this message]
2003-05-10 15:31 ` Jamie Lokier
2003-05-10 17:23 ` Ulrich Drepper
2003-05-10 19:23 ` H. Peter Anvin
2003-05-10 20:52 ` Jamie Lokier
-- strict thread matches above, loose matches on Subject: below --
2003-05-09 17:28 Chuck Ebbert
2003-05-09 17:49 ` Linus Torvalds
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='b9hrhg$5v7$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.