From: george anzinger <george@mvista.com>
To: "Russell King" <rmk@arm.linux.org.uk>,
"christophe barbé" <christophe.barbe@lineo.fr>,
linux-kernel@vger.kernel.org
Subject: Re: How should nano_sleep be fixed (was: ptrace(), fork(), sleep(), exit(), SIGCHLD)
Date: Fri, 17 Aug 2001 11:25:42 -0700 [thread overview]
Message-ID: <3B7D61A6.AF988634@mvista.com> (raw)
In-Reply-To: <20010813093116Z270036-761+611@vger.kernel.org> <20010814092849.E13892@pc8.lineo.fr> <20010814201825Z270798-760+1687@vger.kernel.org> <3B7A9953.744977A5@mvista.com> <3B7AB93D.F8B5B455@mvista.com> <3B7B1B07.A9FB293B@mvista.com> <20010816121746.A5861@pc8.lineo.fr> <20010816112905.A30202@flint.arm.linux.org.uk> <20010816180010.A9235@pc8.lineo.fr> <20010816171248.E30202@flint.arm.linux.org.uk> <3B7C0E3F.24EFB03D@mvista.com>
george anzinger wrote:
>
> 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?
>
How about something like:
In ../asm/signal.h (for i386)
#define PT_REGS_ENTRY(type,name,p1_type,p1, p2_type,p2) \
type name(p1_type p1,p2_typ p2)\
{ struct pt_regs *regs = (struct pt_regs *)&p1;
#define _do_signal() do_signal(regs, NULL)
in ../asm_arm/signal.h
#define PT_REGS_ENTRY(type,name,p1_type,p1, p2_type,p2) \
type name(p1_type p1,p2_typ p2, struct pt_regs *regs) \
{
#define _do_signal() do_signal(NULL,regs, NULL)
and other archs as needed.
in ../linux/signal.h (the default)
:
#include <asm/signal.h>
:
:
#ifndef PT_REGS_ENTRY
#define PT_REGS_ENTRY(type,name,p1_type,p1, p2_type,p2) \
type name(p1_type p1,p2_typ p2)\
{
#define _do_signal() 1
#endif
and finally in nano_sleep :
PT_REGS_ENTRY(asmlinkage long,sys_nanosleep,struct timespec
*,rqtp,struct timespec *,rmtp)
struct timespec t;
unsigned long expire;
:
: etc...
:
do {
current->state = TASK_INTERRUPTIBLE;
} while((expire = schedule_timeout(expire)) && !_do_signal());
The notion is that this could be used for other system calls, in
particular I want to implement clock_nanosleep() as part of the extended
POSIX standard.
Comments, flames,...
George
next prev parent reply other threads:[~2001-08-17 18:28 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-13 8:29 ptrace(), fork(), sleep(), exit(), SIGCHLD Bruce Janson
2001-08-14 7:28 ` christophe barbé
2001-08-14 15:06 ` Bruce Janson
2001-08-15 15:46 ` george anzinger
2001-08-15 17:53 ` george anzinger
2001-08-15 18:02 ` george anzinger
2001-08-16 0:59 ` How should nano_sleep be fixed (was: ptrace(), fork(), sleep(), exit(), SIGCHLD) george anzinger
2001-08-16 10:17 ` christophe barbé
2001-08-16 10:29 ` Russell King
2001-08-16 14:16 ` george anzinger
2001-08-16 16:00 ` christophe barbé
2001-08-16 16:12 ` Russell King
2001-08-16 18:17 ` george anzinger
2001-08-17 18:25 ` george anzinger [this message]
2001-08-17 18:57 ` Victor Yodaiken
2001-08-17 19:56 ` george anzinger
2001-08-22 18:40 ` Russell King
2001-08-23 20:04 ` george anzinger
2001-08-23 20:11 ` Russell King
2001-08-23 21:13 ` george anzinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3B7D61A6.AF988634@mvista.com \
--to=george@mvista.com \
--cc=christophe.barbe@lineo.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=rmk@arm.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox