From: downing.nick@gmail.com (Nick Downing)
Subject: [TUHS] Another odd comment in V6
Date: Tue, 14 Feb 2017 23:46:14 +1100 [thread overview]
Message-ID: <CAH1jEzY6t9p0TsbuEEDisQHpypaGB1_7NUaWHt+7mTUsmdcTAw@mail.gmail.com> (raw)
In-Reply-To: <0B8503D7-D696-4BB6-A2C7-75A95B603036@planet.nl>
Yes, you are right, I had not paid attention to that pc=opc stuff, in
fact 2.9 has a comment saying it's backing the PC up but the other
BSDs do not, so I hadn't noticed that bit. :) I was probably thinking
of another unix that implements it in the C library not the kernel,
however it makes no difference conceptually. Interestingly, 2.11BSD
has ERESTART defined as an errno and does the pc=opc thing if ERESTART
was to have been returned as the errno. Whereas the other BSDs have
another variable eosys which has just a few possible values, where one
of those values (NORMALRETURN or some such) means that errno should be
checked as well. I like the 2.11BSD way. V7 does not have the pc=opc
thing and there is no mention of restarting, so I suppose EINTR just
aborts the interrupted system call.
cheers, Nick
On Tue, Feb 14, 2017 at 11:27 PM, Paul Ruizendaal <pnr at planet.nl> wrote:
> Hi Nick,
>
> Many thanks for that background!
>
> I think the quote from the Gabriel paper indeed refers to software
> interrupts, i.e. signals -- it would not make sense otherwise. The
> ITS system that the MIT guy referred to is 'large', it ran on PDP10
> mainframes.
>
> I understand how executing a signal handler is piggy-backed on the
> return from kernel mode. However, when the signal handler is
> finished it could either continue with the next instruction or
> re-excute the system call trap instruction. See
> http://minnie.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/src/sys/sys/trap.c
> (towards end) for details how this is actually done in 2.9BSD.
> I think you referred to that mechanism as well.
>
> However, my question remains: why is that mysterious comment there,
> above ttread() in V6, and is there a link with the Gabriel story?
>
> Paul
>
> On 14 Feb 2017, at 12:27 , Nick Downing wrote:
>
>> Well I don't know about this actual conversation in history so I can't
>> help with that. But I can describe how interrupted system calls work.
>> [..more..]
>
next prev parent reply other threads:[~2017-02-14 12:46 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-14 8:46 Paul Ruizendaal
2017-02-14 11:27 ` Nick Downing
2017-02-14 12:27 ` Paul Ruizendaal
2017-02-14 12:46 ` Nick Downing [this message]
2017-02-14 14:03 ` Lars Brinkhoff
2017-02-14 14:18 ` Nick Downing
2017-02-14 15:50 ` Random832
2017-02-14 14:14 Noel Chiappa
2017-02-14 14:35 ` Paul Ruizendaal
2017-02-14 15:48 ` Random832
2017-02-14 16:06 ` Dan Cross
2017-02-14 15:40 Noel Chiappa
2017-02-14 16:17 Noel Chiappa
2017-02-21 19:23 Norman Wilson
2017-02-22 9:59 ` Tony Finch
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=CAH1jEzY6t9p0TsbuEEDisQHpypaGB1_7NUaWHt+7mTUsmdcTAw@mail.gmail.com \
--to=downing.nick@gmail.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).