From: Gwenole B. <gbe...@ma...> - 2001-05-31 06:35:47
|
On Wed, 30 May 2001, Christian Bauer wrote: > On Wed, May 23, 2001 at 10:41:45AM +1000, ni...@in... wrote: > > =09Sure. What I actually meant was, what is this mmap() doing: > > > > RAMBaseHost =3D (uint8 *)mmap(0, mapped_ram_rom_size, > > PROT_READ | PROT_WRITE, > > =09=09=09 MAP_PRIVATE, zero_fd, 0); > > > > =09So, how is this really any different to: > > > > RAMBaseHost =3D (uint8 *)malloc(mapped_ram_rom_size); > > Hm, at first glance I can't see the reason. It looks like gbeauchesne wro= te > that part (rev. 1.19 vs. 1.20 of that file); maybe he knows. Perhaps it > simplifies some things by just having to munmap() the area when quitting > istead of either munmap() or free()? Hmm, seems like a residual code from a previous experiment. More seriously, VOSF needs to mmap() the framebuffer area in order to make further calls to mprotect() on it. It is not guaranted that malloc() returns a mmap'ed area though Linux/glibc's implementation tends to call mmap() for big chunks rather than sbrk() or whatever. [1] Now, as for mmap()'ing RAM and ROM as well. IIRC, this comes from Solaris' man page about mmap() and malloc() telling not to mix them if we don't want to be trashed to hell. In other words, this may segfault but I reckon I have not tried it. [1] Just checked a linux/glibc man page about mprotect() and it appears POSIX.1b says that mprotect() can be used only on regions of memory obtained from mmap(). Bye, Gwenol=E9. |