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>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021121214134.P5605-100000>