From owner-cvs-src@FreeBSD.ORG Tue Feb 1 15:41:54 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 A1FD716A4CE; Tue, 1 Feb 2005 15:41:54 +0000 (GMT) Received: from www.portaone.com (support.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD2FC43D2D; Tue, 1 Feb 2005 15:41:53 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [127.0.0.1] (fxp1.moxa.united.net.ua [195.234.212.69]) (authenticated bits=0) by www.portaone.com (8.12.11/8.12.11) with ESMTP id j11FUic4056694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Feb 2005 16:30:45 +0100 (CET) (envelope-from sobomax@portaone.com) Message-ID: <41FFA09E.7070006@portaone.com> Date: Tue, 01 Feb 2005 17:30:38 +0200 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <200501252128.j0PLSSHE081956@repoman.freebsd.org> <200501311814.24008.jhb@FreeBSD.org> <41FEC74F.2080005@portaone.com> <200502010641.59236.jhb@FreeBSD.org> In-Reply-To: <200502010641.59236.jhb@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/685/Wed Jan 26 10:08:24 2005 clamav-milter version 0.80j on www.portaone.com X-Virus-Status: Clean 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/kernkern_time.c src/sys/sys systm.h 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 15:41:54 -0000 John Baldwin wrote: > 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. But you are assigning two members of the same type, no? You aren't assigning "kernel pointer" to "userland pointer", but "userland pointer" to "userland pointer". I am failing to see how it can create any problems. If we can test that pointer to be NULL then we can do this assignment, since both cases require compiler to know the correct size of the pointer. -Maxim