From owner-cvs-src@FreeBSD.ORG Tue Feb 1 14:56:04 2005 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEED016A4E2 for ; Tue, 1 Feb 2005 14:56:00 +0000 (GMT) Received: from mail24.sea5.speakeasy.net (mail24.sea5.speakeasy.net [69.17.117.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 389A743D48 for ; Tue, 1 Feb 2005 14:56:00 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 29800 invoked from network); 1 Feb 2005 14:56:00 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 1 Feb 2005 14:55:59 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j11Etn8T038329; Tue, 1 Feb 2005 09:55:54 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Maxim Sobolev Date: Tue, 1 Feb 2005 06:43:45 -0500 User-Agent: KMail/1.6.2 References: <200501292312.j0TNC0VE052634@repoman.freebsd.org> <200501311441.24275.jhb@FreeBSD.org> <41FEBAE5.7010201@portaone.com> In-Reply-To: <41FEBAE5.7010201@portaone.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200502010643.45784.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/alpha/linux linux_sysvec.c src/sys/alpha/osf1 imgact_osf1.c osf1_sysvec.c src/sys/amd64/linux32 linux32_sysvec.c src/sys/compat/ia32 ia32_sysvec.c src/sys/compat/pecoff imgact_pecoff.c src/sys/compat/svr4 imgact_svr4.c svr4_sysvec.c ... X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 14:56:05 -0000 On Monday 31 January 2005 06:10 pm, Maxim Sobolev wrote: > John Baldwin wrote: > > On Saturday 29 January 2005 06:12 pm, Maxim Sobolev wrote: > >>sobomax 2005-01-29 23:12:00 UTC > >> > >> FreeBSD src repository > >> > >> Modified files: > >> sys/alpha/linux linux_sysvec.c > >> sys/alpha/osf1 imgact_osf1.c osf1_sysvec.c > >> sys/amd64/linux32 linux32_sysvec.c > >> sys/compat/ia32 ia32_sysvec.c > >> sys/compat/pecoff imgact_pecoff.c > >> sys/compat/svr4 imgact_svr4.c svr4_sysvec.c > >> sys/i386/ibcs2 ibcs2_sysvec.c imgact_coff.c > >> sys/i386/linux imgact_linux.c linux_sysvec.c > >> linux_machdep.c > >> sys/kern imgact_aout.c imgact_elf.c imgact_gzip.c > >> imgact_shell.c kern_exec.c kern_kse.c > >> sys/modules Makefile > >> sys/sys imgact.h syscallsubr.h > >> Log: > >> o Split out kernel part of execve(2) syscall into two parts: one that > >> copies arguments into the kernel space and one that operates > >> completely in the kernel space; > >> > >> o use kernel-only version of execve(2) to kill another stackgap in > >> linuxlator/i386. > >> > >> Obtained from: DragonFlyBSD (partially) > >> MFC after: 2 weeks > > > > Cool, this had been on my anti-stackgap todo list as well. > > > :-) > > We have been tolerating this stackgap hack for too long. > > Right now linuxlator/i386 is almost stackgap-free. The only remaining > stackgap is in semctl(2) syscal, which in my opinion it is very > over/under engineered API, so that there is no a good clean way to do > the split. At the same time, it's not the one used oftenly, so that I > can wait when I (or somebody else) is in the right mood to do the > remaining work. > > Other arches/emulation layers are awaiting for somebody (maintainers?) > to do the work, which will be very easy one, since most popular kernel > interfaces that work on userland structures/buffers have been split. That's not the only one. All the filesystem system calls use the stackgap to handle the /compat/linux namespace. Fixing that will not be trivial, as it will involve teaching namei() to retrieve filenames using a uio or some such so that names can either be in user space or in kernel space. Either that or we add native support for prefixes like /compat/foo to namei() by sticking a pointer to a prefix in struct sysent or some such. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org