mmap() is very different in its semantics from read() and write(). The latters have a clear, precise definition, a byte stream received by your file driver. mma

mmap() is very different in its semantics from read() and write(). The latters have a clear, precise definition, a byte stream received by your file driver. mmap() is a different beast, it can be a ring buffer, it can a spinlock, it can be anything. The moment you have mmap(), the "eveything is a file" model is already broken and the namespace API can longer work reliably over the network. How would you transport an mmap() over the network? if /dev/tcp in plan9 uses mmap to asynchronously write the packets, you can no longer rely on the 9p filesystem protocol to implement a proxy by mounting the remote computer's /dev/tcp, because there is no clear and reliable way to map remote memory. It's no more about transporting a random sequence of bytes to another computer. You need more than that to make it work. It's just one example where this "everything is a fike" model is overly simple for the harsh real world.