Intruiging bits in the nsys kernel
Warren Toomey
wkt at henry.cs.adfa.edu.au
Wed Jan 20 08:47:23 AEST 1999
In article by Eric Fischer:
> Congratulations on getting the nsys kernel running! I have
> a couple of random comments on what you posted to the list:
>
> > Syscalls in `nsys' but not in V5:
> > ---------------------------------
> > 1, &quit, /* 26 = quit */
> > 1, &intr, /* 27 = intr */
> > 1, &cemt, /* 29 = cemt */
> > 1, &ilgins, /* 33 = ilgins */
> > 1, &fpe, /* 40 = fpe */
> >
> > These deliver signals QUIT, INTR, EMT, INS or FPE
> > to the pid in arg0. Any user can send these signals.
>
> I think this is backwards -- these system calls don't deliver
> signals, they trap them. That is, they're the predecessors
> of signal(), not kill().
Eric is quite correct, and I realised this after reading some comments
on the V2 kernel. The nsys kernel also has a sig() system call which
allows a process to trap an arbitrary signal. This is why the syscalls
above were removed: there was a more general system call available.
>
> > Syscalls in V5 but not in `nsys':
> > ---------------------------------
> > 0, &getpid, /* 20 = getpid */
> > 1, &smdate, /* 30 = smdate */
> > 0, &nice, /* 34 = nice */
> > 0, &pipe, /* 42 = pipe */ !!!
> > 4, &profil, /* 44 = prof */
>
> This part seems really weird. Since it has fpe() but not nice() and
> pipe(), that would have to mean it's somewhere intermediate between
> v2 and v3, at least if the details in Doug McIlroy's "Research Unix
> Reader" are all accurate. And I *really* don't understand why there
> would be space reserved in the system call table for nice and pipe
> but no implementations of the functions.
>
> The other weird part is that McIlroy says that smdate() was in v1
> through v3 but disappeared after that. I don't have the v5 kernel
> source at hand right now, so I can't check up on that, but it's
> strange that smdate should be missing here if this is an early v3.
>
> Actually, on further inspection this must be a *late* v3, since it
> has mknod(), getgid(), and setgid(), which aren't supposed to have
> shown up until v4. (No signal(), though, so it's not quite v4.)
> That's still very odd that pipes would be left out, unless this
> version was crunched to run in an especially small memory or something.
>
> And yet, v3 was supposed to have been released in February, 1973, and
> this is earlier than that, so what are any v4 features doing there at
> all? This just gets stranger and stranger...
> eric
I've had some chat with Dennis about this kernel, and how it fitted into
development. The summary is: Ken tried to rewrite the assembly version of
the kernel in B (or NB) in 1972, but gave up because structures didn't
exist. Once B -> NB -> C and got structures, they tried again. Apparently,
the `new' kernel (aka nsys) was developed in parallel with the `old'
assembly kernel during early to mid-1973. Then, Dennis says:
I'm pretty sure that we didn't adopt [the C version of the kernel]
as the standard "production" system until about September 1973.
It is very likely that the real "sys" was still in assembler.
Pipes were probably added first to [the sys] version, given the
evidence in "nsys."
Dennis also says:
During 1972, Ken finally puts pipes into Unix at McIlroy's urging.
which would explain why there is a reserved syscall in `nsys', but no
code as yet.
I can't explain the existence of the mknod(), getgid(), and setgid()
system calls. Norman and Bob Keys, I think one/both of you have got the
old manuals, can you look through them and find out when these syscalls
appeared?
Cheers all,
Warren
Received: (from major at localhost)
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id OAA12788
for pups-liszt; Wed, 20 Jan 1999 14:45:43 +1100 (EST)
More information about the TUHS
mailing list