Messages in this thread | | | Date | Sat, 16 Mar 1996 18:02:07 +1000 | From | Jeremy Fitzhardinge <> | Subject | Re: failed shared mmap'ing of /dev/zero |
| |
Sean Foderaro wrote: > > kernel: 1.3.71 > > /dev/zero in linux refuses to do a MAP_SHARED mmap if PROT_WRITE > is also given. > > Other Unixes (sunos, solaris, irix. ...) have no problem with this. > > It's definitely intentional that such a mapping is refused but > it isn't clear why.
Well, what would it mean? If you did this to an ordinary file, it would imply that all processes mmaping from the file and all reads would see changes made through the writable shared mapping. In other words, you change the file contents.
/dev/zero, by definition, always contains zeros: you can't change it. There are two ways you could sensibly and consistently handle shared write mappings: either prevent them altogether, or create a memory mapping which you can write to, but would always read as zero.
Other unicies define some extra semantics for writable shared mappings of /dev/zero. Perhaps it would be worth emulating them, but they would be extentions rather than a logical result of the union of behaviours of writable shared mmap and /dev/zero.
Personally, I've always thought it would be interesting to regard each opening of /dev/zero as containing a separate instance of an infinite number of zeros. That is, if you do a PROT_WRITE MAP_SHARED mmap on an fd, and pass that fd to other processes who also mmap it, you can shared a common piece of memory with no file backing. However, other open instances of /dev/zero wouldn't see the changes, so the global semantics of /dev/zero are maintained. Is this what Solaris and Irix do (I should really know the answer to this, but I've never looked into it).
J
| |