Date: Mon, 31 Jan 2005 18:14:24 -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: <200501311814.24008.jhb@FreeBSD.org> In-Reply-To: <41FE9CC7.4050305@portaone.com> References: <200501252128.j0PLSSHE081956@repoman.freebsd.org> <200501311429.31197.jhb@FreeBSD.org> <41FE9CC7.4050305@portaone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
--
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?200501311814.24008.jhb>
