====== Bringing PDP-7 Unix Back to Life, part 2 ======

Wow! I'm really impressed with the speed at which the [[https://github.com/DoctorWkt/pdp7-unix|PDP-7 Unix restoration team]] has got things up and going. My user-mode simulator is going well. Phil Budne has taken over the care of the assembler and he's also written a shell. I've written tools to make, populate and check the filesystem.

The kernel came up surprisingly easily, much easier than the [[https://github.com/DoctorWkt/unix-jun72|1972 PDP-11 kernel]]. I think we've found only one or two transcription errors. We did have to comment out some code that deals with the "Graphics-2" device, as SimH doesn't simulate this (yet: Phil's working on it).

Once we deduced the format of the password file, init lets us log in and here is what we see:

<code>
login: ken
password: ken
@ ls -l system
00004 drwr- 05 777 00040 dd
00006 srwr- 02 777 00000 ttyin
00007 srwr- 02 777 00000 keyboard
00010 srwr- 02 777 00000 pptin
00013 srwr- 02 777 00000 ttyout
00014 srwr- 02 777 00000 display
00015 srwr- 02 777 00000 pptout
00016 lrwr- 02 777 01773 as
00017 srwr- 02 777 00414 cat
00020 srwr- 02 777 00107 chmod
00021 srwr- 02 777 00107 chown
00022 srwr- 02 777 00056 chrm
00023 srwr- 02 777 00151 cp
00024 srwr- 02 777 00305 date
00025 lrwr- 02 777 00764 ds
00026 lrwr- 02 777 02143 ed
00027 srwr- 02 777 00454 init
00030 srwr- 02 777 00054 ln
00031 srwr- 02 777 00464 ls
00032 srwr- 02 777 00051 mv
00033 srw-- 02 777 00017 password
00034 srwr- 02 777 00507 sh
00035 srwr- 02 777 00311 stat
</code>

Here are just a few things that we've learned about the system.

  * The kernel only really knows about two directories, i-nodes 3 and 4. i-node 3 holds "init" and "sh", and //init//  knows this as the "system" directory. i-node 4 seems to correspond to the "dd" directory, which holds the users' directories according to Dennis' [[https://www.bell-labs.com/usr/dmr/www/hist.html|Evolution paper]].
  * The root user is user-id -1, not zero!
  * There is fork() but no exec(). Both init and the shell have "bounce" code. This small snippet of code is copied up to the top of the process memory, and it loads the new executable code at the bottom of the process memory before jumping to it.
  * There is no concept of file paths, just a current directory. File names are named either relative to the current directory, or in conjunction with a specified directory. For example:

<code>
@ cp abc def                 # Copy abc to def in the current directory
@ ln system sh sh            # Link the sh file in the system directory to sh in this directory
</code>
  * The kernel is agnostic to the concept of "." and ".." entries in each directory. This means that they can be left out, and the system still works: you can always "chdir dd" to get back to the top of the filesystem and then traverse downwards. But if a filesystem is built with "." and ".." links, then the kernel happily treats them like all other links.

Now that we've got the basic system up and running, it's time to bring up the big utilities: //as//  and //ed//. //as//  is working under the user-mode simulator, but we haven't tried it running on the kernel. And, while we have the //ed//  source, it didn't get scanned in very well; we need to get it re-scanned before we can try it out.

Who knows where we will be in another month!