ncm@zembu.com (Nathan Myers) writes:
> This is supported on Linux and BSD, but not on Solarix 7. It's not
> necessary; you can just map /dev/zero on SysV systems that don't
> have MAP_ANON.
HPUX says:
The mmap() function is supported for regular files. Support for any other type of file is unspecified.
> But I don't know of any reason to avoid mapping an actual inode,
How about wasted I/O due to the kernel thinking it needs to reflect
writes to the memory region back out to the underlying file?
> Since mmap() is how everybody implements shared libraries,
Now *there's* a sweeping generalization. Documentation of this
claim, please?
> The mmap architecture comes to us from the Mach microkernel memory
> manager, backported into BSD and then copied widely.
If everyone copied the Mach implementation, why is it they don't even
agree on the spellings of the user-visible flags?
This looks a lot like exchanging the devil we know (SysV shmem) for a
devil we don't know. Do I need to remind you about, for example, the
mmap bugs in early Linux releases? (I still vividly remember having to
abandon mmap on a project a few years back that needed to be portable
to Linux. Perhaps that colors my opinions here.) I don't think the
problems with shmem are sufficiently large to justify venturing into
a whole new terra incognita of portability issues and kernel bugs.
regards, tom lane
