Frame buffer / mmap() weirdness

Geert Uytterhoeven Geert.Uytterhoeven at sonycom.com
Wed Dec 1 20:13:13 EST 1999


On Wed, 1 Dec 1999, Momchil Velikov wrote:
> 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.

Hmmm...

> > 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).

You are right. Since I guess the other mmap()s in the kernel are POSIX
compliant, I feel silly now.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ----------------- Sony Suprastructure Center Europe (SUPC-E)
Geert.Uytterhoeven at sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248632 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/





More information about the Linuxppc-dev mailing list