From owner-cvs-all@FreeBSD.ORG Tue Feb 1 14:55:59 2005 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73AAF16A4CE for ; Tue, 1 Feb 2005 14:55:59 +0000 (GMT) Received: from mail22.sea5.speakeasy.net (mail22.sea5.speakeasy.net [69.17.117.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66F1043D4C for ; Tue, 1 Feb 2005 14:55:58 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 21273 invoked from network); 1 Feb 2005 14:55:58 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 1 Feb 2005 14:55:57 -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 j11Etn8S038329; Tue, 1 Feb 2005 09:55:51 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Maxim Sobolev Date: Tue, 1 Feb 2005 06:41:58 -0500 User-Agent: KMail/1.6.2 References: <200501252128.j0PLSSHE081956@repoman.freebsd.org> <200501311814.24008.jhb@FreeBSD.org> <41FEC74F.2080005@portaone.com> In-Reply-To: <41FEC74F.2080005@portaone.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200502010641.59236.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/compat/linux linux_misc.c src/sys/kern kern_time.c src/sys/sys systm.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 14:55:59 -0000 On Monday 31 January 2005 07:03 pm, Maxim Sobolev wrote: > John Baldwin wrote: > > On Monday 31 January 2005 04:01 pm, Maxim Sobolev wrote: > >>John Baldwin wrote: > >>>On Tuesday 25 January 2005 04:28 pm, Maxim Sobolev wrote: > >>>>sobomax 2005-01-25 21:28:28 UTC > >>>> > >>>> FreeBSD src repository > >>>> > >>>> Modified files: > >>>> sys/compat/linux linux_misc.c > >>>> sys/kern kern_time.c > >>>> sys/sys systm.h > >>>> Log: > >>>> Split out kernel side of {get,set}itimer(2) into two parts: the first > >>>>that pops data from the userland and pushes results back and the second > >>>>which does actual processing. Use the latter to eliminate stackgap in > >>>> the linux wrappers of those syscalls. > >>>> > >>>> MFC after: 2 weeks > >>> > >>>Hmm, I already implemented kern_[sg]etitimer() locally and fixed all the > >>>ABIs, not just Linux to use them. I haven't had time to test the > >>> patches though. Would you be interested in them? > >> > >>I would be happy to, but I don't have any platforms other than i386 > >>(which is why I have not touched other arches). Therefore I am probably > >>a wrong person to do the testing. Is your approach different/better than > >>mine? I'd be happy to do the merge if so. > > > > I've already merged. It's mostly the same except I put the logic to fall > > back to kern_getitimer() when there is no new itimerval in > > kern_setitimer() rather than duplicating that in all the ABIs. > > Well, I had considered such approach, but rejected it because actually > it doesn't win you much since you have to add some logic to avoid > copyin() and submit NULL instead of &aitv to signal kern_setitimer() > that it has to call kern_getitimer() into each ABI instead. As to my > taste such obfuscation (which is duplicated among all ABIs) isn't worth > it. At the same time, linecount wise it is probably the same amount of > duplication anyway. Yes, but modifying struct uap on the fly and assuming you can cast it to the new type without problems is worse IMHO. :) Especially when you have to deal with emulating an ABI like freebsd32 where the pointer sizes are different between the kernel and the userland APP you are running. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org