Re: How should nano_sleep be fixed (was: ptrace(), fork(), sleep(), exit(), SIGCHLD)

From: george anzinger (george@mvista.com)
Date: Thu Aug 16 2001 - 13:17:35 EST


Russell King wrote:
>
> On Thu, Aug 16, 2001 at 06:00:10PM +0200, christophe barbé wrote:
> > Le jeu, 16 aoû 2001 12:29:05, Russell King a écrit :
> > > Note also that this is bogus as an architecture invariant.
> > >
> > > On ARM, we have to pass a pt_regs pointer into any function that requires
> > > it.
> >
> > I'm not sure to understand your point.
>
> Its quite simple:
>
> int sys_foo(struct pt_regs regs)
> {
> }
>
> does not reveal the user space registers on ARM. It instead reveals crap.
> Why? The ARM procedure call standard specifies that the first 4 words
> of "regs" in this case are in 4 processor registers. The other words
> are on the stack immediately above the frame created by foo. This is
> not how the stack is layed out on ARM on entry to a sys_* function
> due to the requirement for these to be restartable.
>
> Instead, we must pass a pointer thusly:
>
> int sys_foo(struct pt_regs *regs)
> {
> }
>
> and the pointer is specifically setup and passed in by a very small
> assembler wrapper.
>
> > The first sentence tell me that the "struct pt_regs ..." line is x86
> > specific and this was the reason behind my proposition to not add a _signal
> > macro but a _sys_nanosleep macro to include this too.
>
> Correct. But the act of getting "struct pt_regs" on entry to the function
> is also architecture specific.
>
> > The second sentence seem's to indicate that this is a classic problem for
> > the ARM port. So if this is correct what is the best way to solve it ?
>
> It used to be with such functions as sys_execve. Then, sys_execve
> became an architecture specific wrapper around do_execve (not by my
> hand), so I guess that its not an ARM specific problem.
>
> --
So, it seems we need an arch. specific wrapper for nano_sleep. Now, how
to do it so it is a smooth transition?

George
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Thu Aug 23 2001 - 21:00:17 EST