Re: [patch] remove hugetlb syscalls

[William Lee Irwin III]

On Thu, 14 Nov 2002 15:20:10 +0100, Christoph Hellwig <[e-mail]> said:
Christoph> mount -t hugetlbfs whocares /huge
Christoph> fd = open("/huge/nose", ..)
Christoph> mmap(.., fd, ..)

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 that
assumes 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, and
he'd better anyway, because he's capable(CAP_IPC_LOCK). Some easy
accommodations could be made, for instance, implicitly truncating the
file to be larger if mmap()'d beyond the end of it, and automatic
placement is easily doable. But I'm not concerned about it at all; the
primary user (IBM's DB2 database) is perfectly capable of dealing with
these constraints on its usage by tweaking buffer pool and other
parameters. Of course, other users may be accommodated if desired.

Bill