Rewriting the GNU Coreutils in Rust

Now I'm wondering how sendfile's performance compares to, say, mmap'ing the file and handing the pointer directly to write (or perhaps fwrite, if we're doing this from userspace). I can't imagine that it could be too much worse than what you describe, seeing as most of the real work is taking place in the page cache, which is supposed to be good at this sort of thing...

Would it be legal/advisable for sendfile to actually be implemented by doing that (with write, not fwrite), in cases where the file to read is mmap'able? Or does that break some sort of "don't alloc buffers in userspace without userspace explicitly asking for it" rule? I can't imagine that any reasonable implementation of malloc would care, but I'm sure there's some ridiculous use case where you go trawling through /proc/self/maps and do something clever with it.

Alternative #2: What if you could mmap file A, somehow tell the kernel that "this mmap now belongs to file B," and then unmap it? I'm guessing that you can't do the second step, though. AFAIK, there's currently no such thing as filesystem-to-memory-to-filesystem COW, so you'd have to fault everything into memory, at which point this is clearly a terrible idea (for large files, anyway).