From: Yufeng Gao
The s1 kernel is, to date, the earliest
machine-readable UNIX kernel,
sitting between V1 and V2.
It will be interesting to see what it reveals, as it's in the UNIX 'dark
age'
between V1 and V4. Working from hints and clues in the extant 'UNIX
Programmer's Manual: Second Edition', I had tried to figure out how V2
differed from V1:
https://gunkies.org/wiki/UNIX_Second_Edition
but I was mostly interested in 'big picture' issues (like how a process'es
address space was laid out), not details like 'the foo() call was added', or
'how exec() differs'. (If someone _does_ create lists of the calls in V1 and
V2, and their details, and compares them, that _will_ be of value, don't get
me wrong; I was mostly just trying to work out how the mysterious KS11
worked.)
It's somewhat picky about the environment. So
far, aap's PDP-11/20
emulator .. is the only one capable of booting the kernel. SIMH and
Ersatz-11 both hang before reaching the login prompt.
It would be very interesting to know what fails. By 'hang', do you mean
'ceases making progress', or 'halts'?
If the former, since I've almost always had good experiences with Ersatz-11,
my _guess_ would be a problem with the RF11 emulation. (The RF11 was a very
early, and smalll, disk, so I wouldn't be surprised if there hasn't been a
lot of software run on those emulators that uses it, to flush out bugs. It's
also kind of an odd duck; it's word-oriented, not block-orientd.) So, for
instance, a 'lost' disk interrupt would produce this symptom. Are there any
RF11 diagnostics online? That would be the thing I would start with.
And I guess this system doesn't include the KS11; a pity, code that uses it
would allow re-creation of the programming manual (the way the:
https://gunkies.org/wiki/ANTS/ISI_IMP_Interface
programming instructions were re-created).
From: Angelo Papenhoff
So the next step would be to restore the assembly
source? :)
Having only the binary to work from (to start with) is not optimal; those
early versions of UNIX ran on a number of very different hardware
configurations (e.g. with or without the KS11), with conditional assembly to
handle different configurations. Having only the dis-assembled code for _this_
configuration would obviously leave the code for the others missing.
Still, having _this_ source _would_ be useful; e.g. the 'hang-up' problem
above; the easiest way to debug that would to put 'print' statements in the
code, where a disk operation was started, and completes. If it's 'losing'
a
disk interrupt completion, that will show right up. (Been there, done that, on
the RK11 hardware emulator Bridgham and I built, when UNIX wouldn't boot, just
hung.) Although I suppose one could put break-points there. Trying to debug it
any other way would be painfu beyond belief.
Noel