>
>In article by Mirian Crzig Lennox:
>> This reminds me that I fixed a couple of "bugs" (some outright bugs,
>> and some mere behaviours which I didn't quite like) in playing with my
>> V6/simh environment, and I'm wondering if there is a place I should
>> submit them in case others might be interested. [ .. ]
Mirian, I'd love to see your fixes! By the way, you might want to
look at
http://www.tuhs.org/Archive/PDP-11/Bug_Fixes/V6enb
for some changes I applied to V6.
Thanks to Warren and Mirian for helping me to undig the "50 bugs tape"!
But the "bugs fixes" look more like performance enhancements. Do you know
any real bugs in V6? By "real" I mean a bug, that might crash the system.
I ask this, because my system crashes ones in a while. But I changed it
here and there, so it might be my fault.
Greetings,
Wolfgang
>
>P.S Does anybody want to backport vi to 6th & 7th Edition?! :-)
Hmm. It's less work to learn ed, so I took that path :-).
In article by Warren Toomey:
> P.S. Does anybody want to backport vi to 6th and 7th Edition?! :-)
The 2BSD tape contains vi source code that can *definitely* be built
on 7th edition (I've done it, it was easy) and supposedly can also
be used to build a 6th-edition "native" vi if you're willing to
backport the V7 C compiler (I haven't done that yet).
Since many people in 2BSD's time frame would not have had access
to V7 systems or V7-ish C compilers, the 2BSD tape also contains a
vi binary for V6 systems.
I think 2BSD was released around the same time as V7, and had an
assumption that many people would not yet have access to V7, and
so would want to use 2BSD as an add-on to V6 systems.
Since 6th edition didn't have environment variables, the 2BSD/V6
version of vi would get the terminal type from a file that mapped
hardwired serial lines to terminal type names. I think it was
called /etc/htmp.
By the way, does anybody else think that vi should have been upgraded
to vii when V7 came out? :-)
Yes there are other bugs you will want to fix as well
if you are using v6 heavily and not on slow hardware
(e.g. a simulator). In the inode allocation route
(ialloc()) in /usr/sys/ken/alloc.c there is a bug in
the placement of the loop: tag. You just have to move
it up two line to above the while() loop. See the diff below.
This rare Ken Thompson bug was found in 1988 on an Amdahl UTS machine
that the hardware finally became fast enough that it caused us panics.
This bug existed from (at least) the Fifth up until the Eighth
editions from 1127 (BTL research). The Ninth edition had much
rewrites in the kernel and the algorthim was changed at that point.
Since it was in UTS, it must have been in the porting base of
System V Release 2. This code is the basis for the System V
filesystem, so it probably didn't exist in BSD releases
since they used their fast filesystem (cylinder groups, et al.)
which became UFS. It's amazing thet with the amount of eyes on it
(via Lions Commentary, etc.) it was not spotted earlier.
It would be good to get a collection of all "unreleased" bug fixes
that others may have.
*** alloc.c.orig Fri Dec 27 23:23:30 2002
--- alloc.c Fri Dec 27 23:23:30 2002
***************
*** 163,171 ****
int i, j, k, ino;
fp = getfs(dev);
while(fp->s_ilock)
sleep(&fp->s_ilock, PINOD);
- loop:
if(fp->s_ninode > 0) {
ino = fp->s_inode[--fp->s_ninode];
ip = iget(dev, ino);
--- 163,171 ----
int i, j, k, ino;
fp = getfs(dev);
+ loop:
while(fp->s_ilock)
sleep(&fp->s_ilock, PINOD);
if(fp->s_ninode > 0) {
ino = fp->s_inode[--fp->s_ninode];
ip = iget(dev, ino);
In article by Mirian Crzig Lennox:
> This reminds me that I fixed a couple of "bugs" (some outright bugs,
> and some mere behaviours which I didn't quite like) in playing with my
> V6/simh environment, and I'm wondering if there is a place I should
> submit them in case others might be interested.
> P.S Does anybody want to backport vi to 6th & 7th Edition?! :-)
'vi' definately works with I+D space under edition 7 (11/44/45/50/53/55/70/73)
There was also an overlayed version for I space only under BSD 2.?, but it was
sooooo slow as to be almost useless
>>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
