Date: Thu, 21 Nov 2002 21:45:09 -0500 (EST) From: Kenneth Culver <culverk@yumyumyum.org> To: freebsd-hackers@freebsd.org Subject: mmap2 implementation for winex Message-ID: <20021121214134.P5605-100000@alpha.yumyumyum.org>
index | next in thread | raw e-mail
Hi,
I recently installed linux winex (again) now that I have working
nVidia drivers. However I found that almost nothing worked and there was a
message about mmap2 not being implemented. I implemented it, but I'm not
sure if it's done right... because some things started working after I
implemented it, but a lot of software that is supposed to work with it
still doesn't. For those who don't know, winex is a version of wine that
supports running windows games that require direct3d to work.
Here is my mmap2 implementation, based on the current mmap:
int
linux_mmap2(struct proc *p, struct linux_mmap2_args *linux_args)
{
struct mmap_args /* {
caddr_t addr;
size_t len;
int prot;
int flags;
int fd;
long pad;
off_t pos;
} */ bsd_args;
bsd_args.flags = 0;
if (linux_args->flags & LINUX_MAP_SHARED)
bsd_args.flags |= MAP_SHARED;
if (linux_args->flags & LINUX_MAP_PRIVATE)
bsd_args.flags |= MAP_PRIVATE;
if (linux_args->flags & LINUX_MAP_FIXED)
bsd_args.flags |= MAP_FIXED;
if (linux_args->flags & LINUX_MAP_ANON)
bsd_args.flags |= MAP_ANON;
else
bsd_args.flags |= MAP_NOSYNC;
if (linux_args->flags & LINUX_MAP_GROWSDOWN) {
bsd_args.flags |= MAP_STACK;
/* The linux MAP_GROWSDOWN option does not limit auto
* growth of the region. Linux mmap with this option
* takes as addr the inital BOS, and as len, the initial
* region size. It can then grow down from addr without
* limit. However, linux threads has an implicit internal
* limit to stack size of STACK_SIZE. Its just not
* enforced explicitly in linux. But, here we impose
* a limit of (STACK_SIZE - GUARD_SIZE) on the stack
* region, since we can do this with our mmap.
*
* Our mmap with MAP_STACK takes addr as the maximum
* downsize limit on BOS, and as len the max size of
* the region. It them maps the top SGROWSIZ bytes,
* and autgrows the region down, up to the limit
* in addr.
*
* If we don't use the MAP_STACK option, the effect
* of this code is to allocate a stack region of a
* fixed size of (STACK_SIZE - GUARD_SIZE).
*/
/* This gives us TOS */
bsd_args.addr = (caddr_t)(linux_args->addr +
linux_args->len);
if (bsd_args.addr > p->p_vmspace->vm_maxsaddr) {
/* Some linux apps will attempt to mmap
* thread stacks near the top of their
* address space. If their TOS is greater
* than vm_maxsaddr, vm_map_growstack()
* will confuse the thread stack with the
* process stack and deliver a SEGV if they
* attempt to grow the thread stack past their
* current stacksize rlimit. To avoid this,
* adjust vm_maxsaddr upwards to reflect
* the current stacksize rlimit rather
* than the maximum possible stacksize.
* It would be better to adjust the
* mmap'ed region, but some apps do not check
* mmap's return value.
*/
p->p_vmspace->vm_maxsaddr = (char *)USRSTACK -
p->p_rlimit[RLIMIT_STACK].rlim_cur;
}
/* This gives us our maximum stack size */
if (linux_args->len > STACK_SIZE - GUARD_SIZE)
bsd_args.len = linux_args->len;
else
bsd_args.len = STACK_SIZE - GUARD_SIZE;
/* This gives us a new BOS. If we're using VM_STACK, then
* mmap will just map the top SGROWSIZ bytes, and let
* the stack grow down to the limit at BOS. If we're
* not using VM_STACK we map the full stack, since we
* don't have a way to autogrow it.
*/
bsd_args.addr -= bsd_args.len;
} else {
bsd_args.addr = (caddr_t)linux_args->addr;
bsd_args.len = linux_args->len;
}
bsd_args.prot = linux_args->prot | PROT_READ; /* always required
*/
if (linux_args->flags & LINUX_MAP_ANON)
bsd_args.fd = -1;
else
bsd_args.fd = linux_args->fd;
bsd_args.pos = ctob(linux_args->pgoff);
bsd_args.pad = 0;
return (mmap(p, &bsd_args));
}
Does anyone see anything blatantly wrong with this?
Ken
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021121214134.P5605-100000>