Messages in this thread | | | Date | Thu, 16 Aug 2001 11:17:35 -0700 | From | george anzinger <> | Subject | Re: How should nano_sleep be fixed (was: ptrace(), fork(), sleep(), exit(), SIGCHLD) |
| |
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/
| |