For a while I had been wondering about the origins of a modification to the V6 kernel that places the kernel buffers in a separately mapped area, freeing up space for other things. It is used in some of the early networking code, i.e. both the UoI code and the V6 BBN code (as available on the TUHS Unix Tree).
I came across the following reference in https://www.osti.gov/scitech/servlets/purl/12130675:
“One widely distributed (though undocumented) solution to this hardware limit on the model 40 was a version of Unix by Robert Sidebotham, Faculty of Environmental Design, University of Calgary. His solution was to move the I/O buffers out of kernel space.”
This would explain the modifications being bracketed with "#ifdef UCBUFMOD”.
Some questions for the old hands:
- Was this patch indeed widely known / distributed?
- Widely distributed is not the same as widely used: was it?
Born on this day in 1925, he was a pioneer in human/computer interaction,
and invented the mouse; it wasn't exactly ergonomic, being just a square
box with a button.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
So, while bringing up V6 on a hardware PDP-11/23 with an RK11 emulator using
an SD card for storage which Dave Bridgham and I are doing, I found this piece
of code in main() on V6 Unix:
rootdir = iget(rootdev, ROOTINO);
rootdir->i_flag =& ~ILOCK;
u.u_cdir = iget(rootdev, ROOTINO);
u.u_cdir->i_flag =& ~ILOCK;
I don't get why two separate calls to iget(), with the same arguments;
why not replace the second pair of lines with:
u.u_cdir = rootdir;
rootdir->i_count++;
What am I missing?
Noel
>>> LSX has a maximum of three processes that are swapped in and out in a
>>> stack-like fashion. Only one process is ever in core.
>
> I'm having a hard time working out how this works. If process A is swapped
> out, and then B, B has to be swapped in before A can be? But only one process
> is ever in core at a time? To get A in, B has to be moved out? But then B
> would be the last one out, and would have to come in before A?
>
> Anyway, I don't understand why the OS could/would care which order processes
> we swapped in - unless it's something like the 'onion skin' memory allocation
> algorithm of CTSS (which also had only a single process resident at a time,
> IIRC), where, when a small process had to be swapped in, and a large one was
> already in, it only swapped out enough of the large one to make room for the
> small one. The process could recurse, hence the name.
The LSI-11 had 40KB of core. The lower 16KB held the LSX kernel, the upper 24K was
for the active process.
LSX has 3 process slots and 2 swap slots (on floppy!). Optionally, LSX could
be built with an additional background process ("BGOPTION"), but this does
not work very well. Process numbers and swap slots have a 1:1 relationship.
There is a global variable, cpid, with the process number of the current
process, initially zero. Upon boot, LSX will load a shell as process 0.
(There is no swapper process and no init in LSX).
The original LSI-11 kernel code is here:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=LSX/sys
I can refer to source lines in the repository for my TI990 port of it:
https://1587660.websites.xs4all.nl/cgi-bin/9995/artifact/b6ec9496e23efe8c
When a process forks, it writes the current core image out to the
corresponding swap slot (this swaps out the parent) and the core image
is repurposed as the new process (i.e. cpid is incremented and the
proc table filled in):
https://1587660.websites.xs4all.nl/cgi-bin/9995/artifact/3617ec3245c40a69?l…
The child now runs and the parent remains suspended until the child completes.
Yes, this implies no pipes. The shell is modified to emulate pipes with files.
When the child completes, it stores its u area / exit code in its swap slot
(as it is running, the swap slot must be empty. Process 3 has a small swap slot
just for this). Next LSX decreases cpid and the parent process is reloaded from
its swap slot:
https://1587660.websites.xs4all.nl/cgi-bin/9995/artifact/b9c07dfc5add9fc5?l…
The actual swapping happens here:
https://1587660.websites.xs4all.nl/cgi-bin/9995/artifact/b6ec9496e23efe8c?l…
The original PDP11 source has code to compress the empty space between _end and the
stack pointer, which I did not get to work properly.
LSX works well enough to run the standard V6 binaries unmodified. Some need to be
tweaked (e.g. table space in cpp) and the shell needed the pipe change. It can run
the V6 c compiler, but not with a wild card argument: that requires 4 stacked processes
(sh, glob, cc and cpp/c0/..) and LSX allows only 3.
Hope the above makes it a bit more clear.
We lost AI pioneer Marvin Minsky on this day in 2016 from a cerebral
haemorrhage, aged 88. Amongst other things, along with John McCarthy he
co-founded the MIT AI Lab, co-invented the Logo "turtle", was mentioned in
Arthur C. Clarke's novel "2001: A Space Odyssey", and built the first
randomly wired neural network learning machine, SNARC, in 1951.
He is now thought to be cryogenically preserved as "Patient 144" at Alcor
(he started cooling on 27/1/2016).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
> From: Doug McIlroy
>> From: Paul Ruizendaal
>> LSX has a maximum of three processes that are swapped in and out in a
>> stack-like fashion. Only one process is ever in core.
I'm having a hard time working out how this works. If process A is swapped
out, and then B, B has to be swapped in before A can be? But only one process
is ever in core at a time? To get A in, B has to be moved out? But then B
would be the last one out, and would have to come in before A?
Anyway, I don't understand why the OS could/would care which order processes
we swapped in - unless it's something like the 'onion skin' memory allocation
algorithm of CTSS (which also had only a single process resident at a time,
IIRC), where, when a small process had to be swapped in, and a large one was
already in, it only swapped out enough of the large one to make room for the
small one. The process could recurse, hence the name.
> V1 was a time-sharing system; for which LIFO swapping is
> inappropriate.
And I don't follow that either...
V1 ran on the 11/20 without memory management hardware, though, right?
(Although there's that cryptic reference to the KS11 in "Odd Comments and
Strange Doings in Unix", although I've never been able to find out anything
else about the KS11.) So presumably one would not have wanted more than one
process resident at a time, as that decreases the odds of a buggy program
trashing another process?
Noel
Hi
I've just had an interesting experience, explaining C header files to
a nephew programmer who didn't understand them. I pointed him in the
direction of Minix as an example of a small well-engineered system
which would display their use.
Which raised the question: when did header files come into use? Who
was the first to use header files to store common system-wide or
application-wide data definitions? Was it used in any languages prior
to C?
Thanks
Wesley Parish
Hi.
Can a modern BSD guru please contact me off-list? I have a set of related
tests in the gawk test suite that consistently fail on just about every
*BSD system. It has me stumped, and I'd like to see these tests working
if possible.
(They've been not working for quite a while. That I get no complaints
from BSD users tells me that gawk isn't popular in that world, but that's
another story. :-)
Thanks,
Arnold
Re: [TUHS] Kernel Sizes
> I've often thought that LSX was V5 'regressed' to the concepts of
> V1, which was facing similar hardware constraints. Is that a
> reasonable view?
> LSX has a maximum of three processes that are swapped
> in and out in a stack-like fashion. Only one process is ever in core.
> Is that how V1 was organized?
The rocess limit was higher in V1. And V1 was a time-sharing
system; for which LIFO swapping is inappropriate. So LSX
seems to have "regressed" to some pre-Unix state.
doug
16K kernels?
Well, I came late to the UNIX world. I only remember getting a SCO
UNIX 3.2V4.2 kernel onto a single 3-1/2" diskette and still have all I
wanted including (with scripts on a second diskette of course :-) ).
That was 25 years ago.
Mind you, from there I moved to Digital UNIX /vmunix 9,613.712, Tru64
17.930.976 to HP-UX 11iv2 66.161.464 and HP-UX 11iv3 127.929.032
Of course, I also got lots more functionality I'm supposed to want and need :-)
Cheers,
rudi