From: george anzinger <george@mvista.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>,
Daniel Jacobowitz <dan@debian.org>,
Jim Houston <jim.houston@ccur.com>,
Stephen Rothwell <sfr@canb.auug.org.au>,
LKML <linux-kernel@vger.kernel.org>,
anton@samba.org, "David S. Miller" <davem@redhat.com>,
ak@muc.de, davidm@hpl.hp.com, ralf@gnu.org, willy@debian.org
Subject: Re: [PATCH] compatibility syscall layer (lets try again)
Date: Tue, 10 Dec 2002 00:20:19 -0800 [thread overview]
Message-ID: <3DF5A3C3.1E395B4E@mvista.com> (raw)
In-Reply-To: Pine.LNX.4.44.0212091051120.1282-100000@home.transmeta.com
[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]
Linus Torvalds wrote:
>
> On Mon, 9 Dec 2002, Martin Schwidefsky wrote:
> >
> > I had been looking at 2.5.50, we had a different meaning of current.
> > If you are saying that for any implementation of nanosleep I have to implement
> > the -ERESTART_RESTARTBLOCK thingy anyway, then I better start with it.
>
> You don't _have_ to. An architecture for which restarting is just too
> painful can just always choose to return -EINTR, that should be ok. That's
> how nanosleep() used to work before - it may not be 100% SuS compliant,
> but it's not as if anybody really cares, I suspect.
>
> Linus
>
You know, if we unwind to where we started all this, Jim was
saying that nanosleep did not know it was being restarted.
You then introduced the restart block AND the new system
call. What if we take a more conservative approach, i.e.
keep the restart block, toss the restart syscall and the
"fn" entry in favor of a "restart" flag. This flag would be
cleared ALWAYS in the deliver path. We could use the
current -ENOHAND and what it does in the no delivery path
(i.e. backs up PC). What we would then have is a restarted
system call with a way to KNOW it was restarted AND a way to
save info it needs to do the restart.
Attached is a patch to take 2.5.50-bk7 to what I am
suggesting. -ERESTART_RESTARTBLOCK is no longer used (I did
not remove the definition), but rather the system call would
return one of the restart system call error codes (-ENOHAND
comes to mind) and at the same time set up the restart
block. On each entry the system call would check to see if
the restart_block.fl was set and if so, do the restart thing
using the saved info. It would be required to clear
restart_block.fl once it found it set...
--
George Anzinger george@mvista.com
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
[-- Attachment #2: restart-2.5.50-bk7.patch --]
[-- Type: text/plain, Size: 1528 bytes --]
--- /usr/src/linux-2.5.50-bk7-posix/arch/i386/kernel/signal.c~ Sat Dec 7 21:36:11 2002
+++ /usr/src/linux-2.5.50-bk7-posix/arch/i386/kernel/signal.c Tue Dec 10 00:06:10 2002
@@ -505,9 +505,8 @@
/* Are we from a system call? */
if (regs->orig_eax >= 0) {
/* If so, check system call restarting.. */
+ current_thread_info()->restart_block.fl = 0;
switch (regs->eax) {
- case -ERESTART_RESTARTBLOCK:
- current_thread_info()->restart_block.fn = do_no_restart_syscall;
case -ERESTARTNOHAND:
regs->eax = -EINTR;
break;
@@ -591,10 +590,6 @@
regs->eax == -ERESTARTSYS ||
regs->eax == -ERESTARTNOINTR) {
regs->eax = regs->orig_eax;
- regs->eip -= 2;
- }
- if (regs->eax == -ERESTART_RESTARTBLOCK){
- regs->eax = __NR_restart_syscall;
regs->eip -= 2;
}
}
--- /usr/src/linux-2.5.50-bk7-posix/include/linux/thread_info.h~ Sat Dec 7 21:36:43 2002
+++ /usr/src/linux-2.5.50-bk7-posix/include/linux/thread_info.h Tue Dec 10 00:12:31 2002
@@ -11,7 +11,7 @@
* System call restart block.
*/
struct restart_block {
- long (*fn)(struct restart_block *);
+ long fl;
unsigned long arg0, arg1, arg2;
};
--- /usr/src/linux-2.5.50-bk7-posix/include/asm-i386/thread_info.h~ Sat Dec 7 21:36:41 2002
+++ /usr/src/linux-2.5.50-bk7-posix/include/asm-i386/thread_info.h Tue Dec 10 00:09:32 2002
@@ -68,7 +68,7 @@
.preempt_count = 1, \
.addr_limit = KERNEL_DS, \
.restart_block = { \
- .fn = do_no_restart_syscall, \
+ .fl = 0, \
}, \
}
next prev parent reply other threads:[~2002-12-10 8:14 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-09 18:41 [PATCH] compatibility syscall layer (lets try again) Martin Schwidefsky
2002-12-09 18:52 ` Linus Torvalds
2002-12-10 8:20 ` george anzinger [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-12-10 17:17 Martin Schwidefsky
2002-12-10 8:42 Martin Schwidefsky
2002-12-09 17:56 Martin Schwidefsky
2002-12-09 18:20 ` Linus Torvalds
2002-12-10 14:40 ` Keith Owens
2002-12-09 17:16 Martin Schwidefsky
2002-12-09 17:33 ` Linus Torvalds
2002-12-09 20:18 ` David S. Miller
2002-12-09 16:58 Mikael Starvik
2002-12-09 17:35 ` Linus Torvalds
2002-12-09 18:46 ` David Mosberger
2002-12-10 0:13 ` Paul Mackerras
2002-12-10 23:11 ` george anzinger
2002-12-04 7:02 Stephen Rothwell
2002-12-04 7:28 ` Stephen Rothwell
2002-12-04 7:30 ` Stephen Rothwell
2002-12-04 7:33 ` Stephen Rothwell
2002-12-04 11:57 ` Pavel Machek
2002-12-04 16:54 ` Linus Torvalds
2002-12-04 16:54 ` David S. Miller
2002-12-04 17:05 ` Linus Torvalds
2002-12-04 19:56 ` george anzinger
2002-12-04 20:07 ` Linus Torvalds
2002-12-04 20:56 ` Daniel Jacobowitz
2002-12-04 22:09 ` David S. Miller
2002-12-04 22:31 ` george anzinger
2002-12-04 22:39 ` David S. Miller
2002-12-04 22:42 ` Linus Torvalds
2002-12-04 23:42 ` Jim Houston
2002-12-05 0:18 ` Linus Torvalds
2002-12-05 2:01 ` george anzinger
2002-12-05 2:51 ` Linus Torvalds
2002-12-05 3:10 ` Andi Kleen
2002-12-05 3:46 ` george anzinger
2002-12-05 4:11 ` Linus Torvalds
2002-12-05 7:10 ` george anzinger
2002-12-05 9:48 ` george anzinger
2002-12-05 15:24 ` Jim Houston
2002-12-05 16:35 ` george anzinger
2002-12-06 0:03 ` Richard Henderson
2002-12-05 17:03 ` Linus Torvalds
2002-12-06 9:17 ` george anzinger
2002-12-06 17:57 ` Linus Torvalds
2002-12-06 19:20 ` Linus Torvalds
2002-12-06 20:18 ` george anzinger
2002-12-06 21:12 ` Linus Torvalds
2002-12-06 21:56 ` Jim Houston
2002-12-06 22:58 ` Linus Torvalds
2002-12-07 2:25 ` george anzinger
2002-12-06 23:08 ` george anzinger
2002-12-08 20:41 ` David S. Miller
2002-12-09 6:18 ` Stephen Rothwell
2002-12-09 15:41 ` Daniel Jacobowitz
2002-12-09 16:48 ` Linus Torvalds
2002-12-09 17:27 ` David Mosberger
2002-12-09 20:22 ` David S. Miller
2002-12-09 17:49 ` Jim Houston
2002-12-09 17:57 ` Linus Torvalds
2002-12-09 23:30 ` Paul Mackerras
2002-12-10 23:07 ` george anzinger
2002-12-11 7:10 ` Daniel Jacobowitz
2002-12-11 8:11 ` george anzinger
2002-12-11 8:26 ` Daniel Jacobowitz
2002-12-10 11:08 ` Jamie Lokier
2002-12-05 2:27 ` Jim Houston
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=3DF5A3C3.1E395B4E@mvista.com \
--to=george@mvista.com \
--cc=ak@muc.de \
--cc=anton@samba.org \
--cc=dan@debian.org \
--cc=davem@redhat.com \
--cc=davidm@hpl.hp.com \
--cc=jim.houston@ccur.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ralf@gnu.org \
--cc=schwidefsky@de.ibm.com \
--cc=sfr@canb.auug.org.au \
--cc=torvalds@transmeta.com \
--cc=willy@debian.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.