From: Daniel Jacobowitz <dan@debian.org>
To: george anzinger <george@mvista.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
Linus <torvalds@transmeta.com>,
LKML <linux-kernel@vger.kernel.org>, Jeff Dike <jdike@karaya.com>
Subject: Re: [PATCH] make do_signal static on i386
Date: Wed, 9 Oct 2002 15:37:38 -0400 [thread overview]
Message-ID: <20021009193738.GA15232@nevyn.them.org> (raw)
In-Reply-To: <3DA46A17.447B2C59@mvista.com>
On Wed, Oct 09, 2002 at 10:40:39AM -0700, george anzinger wrote:
> This will cause problems for nano_sleep and
> clock_nanosleep. These system calls need to call
> do_signal() in order to meet the POSIX standard which states
> that they are interrupted only by signals that are delivered
> to user code. Other signals are not to interrupt the
> sleep. This is why do_signal() returns this information to
> the caller.
>
> I suppose one could argue that such functions should be in
> signal.c, but save for this signal issue the code is
> common. Seems a waste to support the same code in N
> platforms.
IMO, calling the architecture's do_signal function to handle that is
entirely the wrong way to go. They don't even all have the same
arguments, and the wrappers hi-res-timers put around sys_nanosleep are
hideous.
All of this should be handled correctly in kernel/signal.c, and things
like triggering the debugger should be done from there, not duplicated
in each platform's signal delivery code.
Ideally we should even trigger the debugger without necessarily
knocking the sleeping process out of sleep.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
next prev parent reply other threads:[~2002-10-09 19:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-09 8:10 [PATCH] make do_signal static on i386 Stephen Rothwell
2002-10-09 11:30 ` Jeff Dike
2002-10-09 17:40 ` george anzinger
2002-10-09 19:37 ` Daniel Jacobowitz [this message]
2002-10-09 20:22 ` george anzinger
[not found] <20021009181003.022da660.sfr@canb.auug.org.au.suse.lists.linux.kernel>
2002-10-09 8:18 ` Andi Kleen
2002-10-10 7:23 Pavel Machek
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=20021009193738.GA15232@nevyn.them.org \
--to=dan@debian.org \
--cc=george@mvista.com \
--cc=jdike@karaya.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
--cc=torvalds@transmeta.com \
/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;
as well as URLs for NNTP newsgroup(s).