From: ebiederm@xmission.com (Eric W. Biederman)
To: James McKenzie <kernel@ostrich.dhs.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: alpha 4K mmap offsets and em86
Date: 23 Sep 2001 06:55:51 -0600 [thread overview]
Message-ID: <m1adzm83s8.fsf@frodo.biederman.org> (raw)
In-Reply-To: <20010923123042.B32649@hecate.esc.cam.ac.uk>
In-Reply-To: <20010923123042.B32649@hecate.esc.cam.ac.uk>
James McKenzie <kernel@ostrich.dhs.org> writes:
> Hi,
>
> very sorry if this has been discussed before I couldn't
> find any references in the archive. There is a program
> on the alpha architecture which can (with a little help
> from the kernel) execute ia32 linux binaries it's useful
> if you need to run badly written 32 bit code.
>
> The emulator needs to mmap elf binaries in, and
> offsets in ia32 elf files are 4k aligned for a 4k
> pagesize. On 2.2 on an alpha you could do
> mmap(NULL,3176, ... , fd, 0x1000);
> but now in 2.4 but in 2.4 it returns EINVAL.
>
> The code in mm/mmap.c and vm_area_struct seem to
> now count the offset in pages rather than bytes,
> which would make fixing this ugly [maybe an element
> in the structure to store 'slop' ?]
Nope. This change was rather important to simplifying
the page cache, so having slop is not really what we want. Having
slop is actually a coherency nightmare.
You can do: mmap(/dev/zero, size) read(binary) if you
really nead that functionality. Unless you are running
many instances of a program it really shouldn't matter.
Also you can't emulate full x86 semantics whatever you do because you
don't have 4K granularity.
There are actually processors where it is worse, and you need
something like 64K alignment despite the fact they have 4K pages.
That is needed to avoid conflicts in virtually indexed L1 caches.
Eric
next prev parent reply other threads:[~2001-09-23 13:04 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-23 11:30 alpha 4K mmap offsets and em86 James McKenzie
2001-09-23 12:55 ` Eric W. Biederman [this message]
2001-09-24 23:52 ` Richard Henderson
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=m1adzm83s8.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc=kernel@ostrich.dhs.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox