From: Eric W Biederman <eric@flinx.npwt.net>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: "Benjamin C.R. LaHaise" <blah@kvack.org>,
Bill Hawes <whawes@transmeta.com>,
Linux-kernel <linux-kernel@vger.rutgers.edu>,
linux-mm@kvack.org
Subject: Re: writable swap cache explained (it's weird)
Date: Sat, 1 Aug 1998 23:54:03 -0500 (CDT) [thread overview]
Message-ID: <Pine.LNX.4.02.9808012342400.424-100000@iddi.npwt.net> (raw)
In-Reply-To: <Pine.LNX.3.96.980730142318.6696A-100000@penguin.transmeta.com>
On Thu, 30 Jul 1998, Linus Torvalds wrote:
>
>
> On Thu, 30 Jul 1998, Benjamin C.R. LaHaise wrote:
> >
> > (a) sounds like the Obvious Thing To Do in the mmap method for /proc, but
> > will break xdos. Wtf were they thinking in writing that insane code?
> > Hmmm, this bug probably applies to 2.0 too.... in a much more subtle
> > fashion.
>
> The insane code is indeed insane, but I think I understand why they did
> it: they didn't want to mess around with sysv shared memory regions.
Good guess but no. Dosemu already uses sysv shared memory regions
where it can. But for some applications it needs page level control,
and sysv doesn't give you that.
Further the dosemu history states that when it was attempted to map a
temporary file, and use the standard mmap functionality that way, the
performance became unacceptable on nfs filesystems.
So /proc/self/mem was the only solution open to dosemu, that provided
the required level of performance and control.
> I'd love to just completely get rid of mmap() on /proc/self/mem, because
> it actually is a bad idea completely (not just the shared mappings - even
> a private mapping of another mapping that is shared has simply completely
> untenable logical problems).
I agree and this is why I have put a considerable amount of effort into
implementing a posix shared memory interface.
Eric
--
This is a majordomo managed list. To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org
prev parent reply other threads:[~1998-08-02 4:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <35BF43AC.F0F0C14F@transmeta.com>
1998-07-30 19:20 ` Benjamin C.R. LaHaise
1998-07-30 19:49 ` Bill Hawes
1998-07-30 21:25 ` Linus Torvalds
1998-07-30 23:14 ` Richard Gooch
1998-08-02 4:54 ` Eric W Biederman [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=Pine.LNX.4.02.9808012342400.424-100000@iddi.npwt.net \
--to=eric@flinx.npwt.net \
--cc=blah@kvack.org \
--cc=ebiederm+eric@npwt.net \
--cc=linux-kernel@vger.rutgers.edu \
--cc=linux-mm@kvack.org \
--cc=torvalds@transmeta.com \
--cc=whawes@transmeta.com \
/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