>>When a process terminates (in sys1.c/exit()), it explicitly wakes up
>>the init process. In light of the fact, that every process has a parent,
>>this extra wakeup(&proc[1]) seems unnecessary.
>
>I believe this is meant to handle the case where a process exits
>without having called wait() on its children.
>
>Imagine two processes, A and B, where A is B's parent and A's parent
>is some process other than init. B calls exit(), becomes a zombie,
>and awakens A. Some time later, A calls exit() without ever having
>called wait(). This will cause B to become a child of init, and as B
>is a zombie, init should awaken so that B can die. However, A might
>have any number of zombie children, and it would be redundant to call
>wakeup(&proc[1]) for each one. Therefore, the wakeup call to init is
>done up front, whether it is needed or not. This does result in some
>unnecessary wakeup calls but on the whole it seems a good tradeoff for
>code simplicity.
Oh, I see! So the condition to wakeup init would be
"Do I have any zombie children"?
The code as it is is simpler. But harder to understand.
Thank you very much for your help!
Greetings
Wolfgang Helbig
Hi,
encouraged by the profound answers I thankfully recieved to my previous
question about the Unix V6 kernel, here is another one:
When a process terminates (in sys1.c/exit()), it explicitly wakes up
the init process. In light of the fact, that every process has a parent,
this extra wakeup(&proc[1]) seems unnecessary. Furthermore, the "goto loop:"
at the end of exit() will never be executed.
So is this just defensive programming, or did I miss something?
Greetings,
Wolfgang Helbig
Dear All,
There is a complete 11/34 for sale on EBay (1 day to go). It comes with
a complete V6 with source.
Somebody buy it please. This is nothing to do with me, I just saw it
tonight. It's in Pontypridd South Wales
Cheers
Robin
--
Robin Birch
Yes, I have v6 running on an 11/34; it's amazing how easy it is to
corrupt the filesystem. :-) One of these days, I need to dd another
fresh system disk (RK05) off my "sacred copy" of a PUPS image (tediously
transferred via 9600 baud serial using Warren's excellent vtserver
tools). In any case, why do you ask? - Ian
-----Original Message-----
From: Wolfgang Helbig [mailto:helbig@Informatik.BA-Stuttgart.DE]
Sent: Saturday, December 14, 2002 12:48 AM
To: tuhs(a)minnie.tuhs.org
Subject: Re: [TUHS] re: Raise of interrupt level necessary
[snip]
I also removed IPL protection from the return sequence of the trap
routine, still works. Testing was done on Bob Supnik's SIMH PDP-11
simulator with only one terminal. By the way, is anyone running V6 on a
real PDP-11? [snip]
>Date: Sat, 14 Dec 2002 15:27:40 -0800
Michael Davidson wrote:
>If you think that the "rule" is "no ISR can touch user space while
>interrupting a kernel process", then it is display() that breaks
>the rule.
The point is, that this rule leads to somewhat simpler and therefore
better code -- breaking the rule calls for some justification.
Calling display() from the clock-ISR is the only place where an ISR does
not conform to this rule.
Greetings
Wolfgang Helbig
Dennis, I greatly appreciate your reply. What amazes me most, is the fact
that after 20 odd years you still remember those tricky details:
>For example, the clock interrupt routine can inspect user
>space (for display(), for example, though this is inactive
>on the 11/40), and even change it (for profiling).
>It does appear that other things (checking for
>a direct-from user-mode interrupt) in the clock routine
>already guard against these particular problems.
To see what happens, I just removed those IPL raising instructions from gword,
pword,_savu, _aretu, _copyseg, and _clearseg in m40.s. In fact, it didn't crash
the system. At least on my configuration, ISRs don't touch user space while
interrupting a kernel process. This rule is broken by the clock ISR, which calls
display() unconditionally. Just curious: Is there any other reason beside
seeing blinking lights that justifies calling display() 60 times per second
and breaking the rule?
I also removed IPL protection from the return sequence of the trap routine,
still works. Testing was done on Bob Supnik's SIMH PDP-11 simulator with only
one terminal. By the way, is anyone running V6 on a real PDP-11? Here
is the diff of my modifications to m40.s:
# diff m40.s.6 m40.s
44d43
* bis $340,PS
455,456d453
* mov PS,-(sp)
* bis $340,PS
472,473d468
* mov PS,-(sp)
* bis $340,PS
480d474
* mov (sp)+,PS
485d478
* mov (sp)+,PS
539d531
* bis $340,PS
548d539
* bis $340,PS
594c585
* mov $30340,PS
---
. bis $30000,PS
621c612
* mov $30340,PS
---
. bis $30000,PS
Greetings,
Wolfgang Helbig
I know it causes one to salivate like Pavlov's
dogs, even thinking about them, but, anyone know
of any qbus scsi controllers that might someday
come available at anything like reasonable sorts
of guildern de realme?
(running and ducking for cover....(:+]].....)
Just thought I would check.
Thanks
Bob
The particular webster wqesd4 I have looks like
about an '86 or so board, from chip dates, and
the main chip that is socketed is marked with
"ENGR-SAMPLE"...doh.... Maybe I do have a very
early board that won't run with a faster cpu.
The rom is a part no. 080469-01 REV 01, if that
means anything to anyone, as marked on its paper
label. The later sigma board does not have the
problem. Oh, well, if I have to run it with a
KA630 at slo-poke gait, so be it....(:+\\...
There are two diodes, one looks like an ordinary
silicon rectifier and one looks like a zener of
some sort, possibly, off pin 19 of the 74ls240
at position V2 on the board. Those come off
the J6 pin 10 of 10, and are in parallel.
Thanks
Bob
Early ROM revisions on the Webster MSCP controllers were too slow for the
KA650 and would often loose interrupts (amoungst other things). Signals such
as NPR and BR grants were polled from a pseudo microcode loop which took too
long.
The RS232 interface doesn't use standard receivers. Check for a 5 volt zener on
the input of an 74LS240 (from the 10 pin i/o connector) and add a schottky
in parallel (a 1N5818 would do) if one isn't there