From: Momchil Velikov <velco@fadata.bg>
To: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Cc: Stephen Edie <sedie@terraplex.com>,
linuxppc-dev@lists.linuxppc.org,
yellowdog-devel@lists.yellowdoglinux.com
Subject: Re: Frame buffer / mmap() weirdness
Date: Wed, 01 Dec 1999 10:16:10 +0200 [thread overview]
Message-ID: <3844D94A.18E9C52C@fadata.bg> (raw)
In-Reply-To: Pine.GSO.4.10.9912010822250.16291-100000@dandelion.sonytel.be
Geert Uytterhoeven wrote:
>
> On Tue, 30 Nov 1999, Stephen Edie wrote:
> > Furthermore, it makes most sense that mmap() should take care of page
> > alignment issues for me so that the address returned by mmap() always
> > points to the data at [lseek(h, 0, SEEK_SET)]. This is not technically
> > difficult to implement, right?
This behavior is mandated by POSIX:
" pa = mmap( addr, len, prot, flags, fildes, off)
The mmap() function establishes a mapping between the address space of
the process at an address pa for len bytes for memory object represented
by the file descriptor fildes at offset off for len bytes".
So, if pa[0] != [lseek(fildes, off, SEEK_SET], etc., the mmap()
implementation is clearly buggy or at least non-compliant.
> I think it will make munmap() more difficult to implement. Furthermore I see no
> provisions for this in the current mmap() code. And it will break backwards
> compatibility.
Don't know for mmap(), but it seems the only change to munmap() is
to clear the appropriate number of low-order bits in its first argument
( addr & 0xfffff000 for 32-bit machines with 4k page size).
Regards,
-velco
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~1999-12-01 8:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-11-30 22:06 Frame buffer / mmap() weirdness Stephen Edie
1999-11-30 21:19 ` Geert Uytterhoeven
1999-11-30 22:43 ` Stephen Edie
1999-12-01 7:28 ` Geert Uytterhoeven
1999-12-01 8:16 ` Momchil Velikov [this message]
1999-12-01 9:13 ` Geert Uytterhoeven
1999-12-01 9:54 ` Gabriel Paubert
1999-12-01 11:02 ` Momchil Velikov
1999-12-01 13:02 ` Gabriel Paubert
1999-12-01 15:06 ` Momchil Velikov
1999-12-01 11:12 ` Michael Schmitz
1999-12-01 9:26 ` Michael Schmitz
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=3844D94A.18E9C52C@fadata.bg \
--to=velco@fadata.bg \
--cc=Geert.Uytterhoeven@sonycom.com \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=sedie@terraplex.com \
--cc=yellowdog-devel@lists.yellowdoglinux.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;
as well as URLs for NNTP newsgroup(s).