i've been skimming through the compat mmap routines on my way to
cleaning things up to make "top down" memory allocation work properly,
and i've found a few things that confuse me.  as an example, here's a
snippet from ibcs2_sys_mmap() in compat/ibcs2/ibcs2_misc.c:

	SCARG(&mm, prot) = SCARG(uap, prot);
	SCARG(&mm, len) = SCARG(uap, len);
	SCARG(&mm, flags) = SCARG(uap, flags) & ~_MAP_NEW;
	SCARG(&mm, fd) = SCARG(uap, fd);
	SCARG(&mm, addr) = SCARG(uap, addr);
	SCARG(&mm, pos) = SCARG(uap, off);

	rp = (void *) round_page((vaddr_t)p->p_vmspace->vm_daddr + MAXDSIZ);
	if ((SCARG(&mm, flags) & MAP_FIXED) == 0 &&
	    SCARG(&mm, addr) != 0 && SCARG(&mm, addr) < rp)
		SCARG(&mm, addr) = rp;

	return sys_mmap(p, &mm, retval);

as you can see, the parameters to the compat call are copied and then
passed to the "native" sys_mmap() call.  what i don't understand is
the reasoning for the gyrations on the addr parameter.  the
circumstances under which rp is assigned to SCARG(&mm, addr) are the
same as the ones where sys_mmap() would do exactly the same thing like
this:

	if (flags & MAP_FIXED) {
		...
	} else {
		...
		addr = MAX(addr, round_page((vaddr_t)p->p_vmspace->vm_daddr +
					    MAXDSIZ));
	}

why the extra work?

this is the virtually same as sunos_sys_mmap(), svr4_sys_mmap(),
svr4_sys_mmap64(), and ultrix_sys_mmap().

i can see why it might be done in svr4_32_sys_mmap(), maybe in
svr4_32_sys_mmap64(), and sunos32_sys_mmap().  they're designed to
operate in a mixed 32/64 bit environment, right?

the way that px_mmap_info() works is similar, but different in that it
calls on uvm_mmap() to do the work, so it needs to pick a reasonable
default itself, though i wonder if it couldn't be converted to use
sys_mmap() instead.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."