On Thu, Nov 14, 2002 at 09:51:55AM -0800, David Mosberger-Tang wrote:> One potential downside of this is that programmers might expect> mremap(), mprotect() etc. to work on the returned memory at the> granularity of base-pages. I'm not sure though whether that was part> of the reason Linus wanted separate syscalls.> --david

I'm not entirely sure. There is quite a bit about this filesystem thatassumes the user already knows what he's doing, for instance:

(1) CAP_IPC_LOCK is required to access anything on it(2) only mmap() and truncate() are supported(3) ->f_op->mmap() will hand -EINVAL back to userspace instead of automatically placing the vma, for explicit and 0 start adresses(4) ->f_op->mmap() will also hand back -EINAL if one attempts to mmap() beyond the end of the file

There is the assumption that the user knows what he's doing here, andhe'd better anyway, because he's capable(CAP_IPC_LOCK). Some easyaccommodations could be made, for instance, implicitly truncating thefile to be larger if mmap()'d beyond the end of it, and automaticplacement is easily doable. But I'm not concerned about it at all; theprimary user (IBM's DB2 database) is perfectly capable of dealing withthese constraints on its usage by tweaking buffer pool and otherparameters. Of course, other users may be accommodated if desired.