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