Date: Tue, 1 Feb 2005 06:41:58 -0500 From: John Baldwin <jhb@FreeBSD.org> To: Maxim Sobolev <sobomax@portaone.com> 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 Message-ID: <200502010641.59236.jhb@FreeBSD.org> In-Reply-To: <41FEC74F.2080005@portaone.com> References: <200501252128.j0PLSSHE081956@repoman.freebsd.org> <200501311814.24008.jhb@FreeBSD.org> <41FEC74F.2080005@portaone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200502010641.59236.jhb>