> when you're working below the reliable stream level, you can't just do a
> blocking 'read' for a packet; it pretty much has to be asynchronous
Oh, you should look at the early BBN TCP for V6 Unix - they would have faced
the same issue, with their TCP process. They did have the capac() call (which
kind of alleviates the need for non-blocking I/O), but that may have only been
available for ports/pipes; I'm not sure if the ARPANET device supported it.
(With the NCP as well, that did some amount of demultiplexing in the kernel,
and probably had buffering there, so, if so, in theory capac() could have been
done there. Of course, with the ARPANET link being only 100Kbit/sec maximum -
although only to a host on the same IMP - the overhead of copying buffered
data made kernel buffering more 'affordable'.)
Noel
> From: Paul Ruizendaal
> This time looking into non-blocking file access. (... right now my
> scope is 'communication files' (tty's, pipes, network connections).
> ...
> First appearance of non-blocking behaviour seems to have been with
> Chesson's multiplexed files ... in 1979.
At around that point in time (I don't have the very _earliest_ code, to get an
exact date, but the oldest traces I see [in mapalloc(), below] are from
September '78), the CSR group at MIT-LCS (which were the people in LCS doing
networking) was doing a lot with asynchronous I/O (when you're working below
the reliable stream level, you can't just do a blocking 'read' for a packet;
it pretty much has to be asynchronous). I was working in Unix V6 - we were
building an experimental 1Mbit/second ring - and there was work in Multics as
well.
I don't think the wider Unix community heard about the Unix work, but our
group regularly filed updates on our work for the 'Internet Monthly Reports',
which was distributed to the whole TCP/IP experimental community. If you can
find an archive of early issues (I'm too lazy to go look for one), we should
be in there (although our report will alsocover the Multics TCP/IP work, and
maybe some other stuff too).
There were two main generations of code; I don't recall the second one well,
and I'm too lazy to go look, but I can tell you off the top of my head a bit
about how the first one worked. Open/read/write all looked standard to the
user in the process (the latter two were oriented to packets, a bit like raw
disks being blocks); multiple operations could be queued in each
direction. (There was only one user allowed at a time for the network device;
no input demultiplexing.)
Whenever an I/O operation completed, the process was sent a signal. Since the
read/write call had long since returned, it had to do a getty() to get info
about that operation - the size of the packet, error indications, etc.
One complication was that for a variety of reasons (we wanted to avoid having
to copy data, and the interface did not have packet buffers) we did DMA
directly to/from the user's memory; this meant the process has to be locked
in place while I/O was pending.
(I didn't realize it at the time, but we dodged a bullet there; a comment
in xalloc(), which I only absorbed recently, explains the problem. More
here:
https://gunkies.org/wiki/UNIX_V6_internals#exec()_and_pure-text_images
if anyone wants the gory details.)
That all (the queing, signals for I/O completion, locking the process to a
fixed location in memory while it continued to run) etc all worked well, as I
recall (although I guess it couldn't do an sbrk() while locked), but one
complication was the UNIBUS map on the -11/70.
The DSSR/RTS group at LCS wanted to have a ring interface, but their machine
was a /70 (ours, the one the driver was initially done on/for, was a /40), so
with DMA we had to use the UNIBUS map.
The stock V6 code had mapalloc(), (and mapfree(), both called on all DMA
operations), but... it allocated the whole map to whatever I/O operation asked
for the map. Clearly, if you're about to start a network input operation, and
wait a packet to show up, you don't want the disk controller to have to sit
and wait for for a packet to show up so _it_ can have the map.
Luckily, mapalloc() was called with a pointer to the buffer header (which had
all the info about the xfer), so I added a 'ubmap' array, and called the
existing malloc() on it, to allocate only a big enough chunk of the UNIBUS map
for the I/O operation defined by the header. Since there was 248KB of map
space, and the largest single DMA transfer possible in V6 was about 64KB
(maybe a little more, for a max-sized process with its 'user' block), there
was never a problem with contention for the map, and we didn't have to touch
any of the other drivers at all.
That was dandy, and only a couple of lines of extra code, but I somehow made a
math error in my changes, and as I recall I had to debug it with a printf() in
mapalloc(). I was not popular that day! Luckily, the error was quickly
obvious, a fix was applied, and we were on our way.
Noel
> Team Unix, Is there a Windows or Linux utility to create a disk image in any of the above formats, from a local folder tree? Paul *Paul Riley*
It seems you are asking for two tools in the BK-UNIX toolbox, fsutil and dskutil
https://github.com/sergev/bkunix/tree/master/fsutilhttps://github.com/sergev/bkunix/tree/master/diskutil
The first generates a Unix 6th edition file system from a local directory tree. The result is a binary file with the 512 byte disk blocks stored in sequence. Maybe this is what SIMH needs, I’m not into the details of SIMH.
The second appears to be a tool to take the a file generated by the fsutil tool and split that into sectors and tracks. I’m not familiar with this tool, but it looks like you might need something similar (I assume that you have some way to hook up a 8” drive to your PC?). Sector interleaving may be an issue to look out for.
When preparing a LSX system disk, you will need to think carefully about the layout:
Presumably the disk works with 128 byte sectors and 4 sectors are grouped together to create a 512 byte unix block. Check out the disk driver code for details:
https://www.tuhs.org/cgi-bin/utree.pl?file=LSX/sys/decfd.c
Block 0 contains bootstrap code which is loaded/called from the monitor rom (or from a short code sequence keyed in on a “blinkenpanel” console).
The filesystem itself starts at block 1 and runs up to a block N (you need to tell fsutil how big the filesystem needs to be).
After block N up to the end of the disk is space to contain 2 swapped out programs plus 1 block for the return code of the third (default LSX has a maximum of 3 processes). You have to figure out how many 512 blocks are on your floppy and subtract out the swap space to arrive at a figure for N.
In the LSX source code ’N’ is known as the define SWPLO, see param.h for details:
https://www.tuhs.org/cgi-bin/utree.pl?file=LSX/sys/param.h
In this file, 99 blocks are reserved for swap, corresponding to processes with 24KB memory; total disk size is defined as 500 blocks, 250KB - note that this slightly exceeds the 241KB offered by the standard IBM 77 track 26 sector formatting for 8” disks. Probably you will need to tweak the values in param.h
Be careful with size units in the source code. Often sizes are expressed in words (2 bytes). Where memory is concerned it is often expressed in ‘clicks’, 64 bytes.
I've managed to acquire a PDP-11/03 with twin floppy drives (Sykes
Datatronics RX01 or RX02 equivalents, not sure yet which).
I've stumbled across LSX, and I have it running on SimH. I'm quite
inexperienced with Unix, but it's something I want to learn well, having
brushed against it at university in the '80s, and having played with Linux
somewhat.
I have some interest in Forth, but I don't like the block system of early
forths such as FigForth, and I plan to create a new Forth based on
FigForth, but supporting external source files.
Anyway, I've tried compiling Hello World on LSX, and I get "1: External
definition syntax" error. Some help would be nice, but more generally, is
anyone on this list more than vaguely familiar with LSX, or 6th Edition
itself?
void main () {
printf("Hello World!");
}
It seems that the 7th Edition was the beginning of the standard library in
C, and that this is missing in LSX. I'm not sure if printf is an intrinsic
function in (6th Edition) C, or if it's from a library.
My questions are a bit random, but looking to converse with others with LSX
experience.
Paul
*Paul Riley*
Email: paul(a)rileyriot.com
>
> In this file, 99 blocks are reserved for swap, corresponding to processes with 24KB memory; total disk size is defined as 500 blocks, 250KB - note that this slightly exceeds the 241KB offered by the standard IBM 77 track 26 sector formatting for 8” disks. Probably you will need to tweak the values in param.h
Oops: 77 tracks by 26 sectors of 128 bytes, makes 250.25KB, so it should work as configured.
Hoi,
personally I use fmt(1) a lot for email formatting and such.
Typically I only use the `-w' parameter. Now someone asked me about
`-t' and `-c' of *GNU* fmt(1). I wasn't able to find good documentation
on them. The manpage only tells that they have to do with different
indentation for the first or first two lines. But what are the use
cases? How would source text for these parameters look like?
A look into the description and rationale sections of POSIX, which
often provides helpful information, was not possible because fmt(1)
is not part of POSIX (only fold(1) is). Why's that? Is it because
fmt(1) differs so much between Unix implementations? On BSD `-c'
centers text and `-t' sets tab widths. Plan 9 has none of these
options. But still, `-w' could have been standardized. Or was the
line filling algorithm different as well? How does fold(1) fit into
the picture?
Maybe you can answer some of these questions or give hints on where
I could find answers myself.
meillo
> I've stumbled across LSX, and I have it running on SimH. I'm quite inexperienced with Unix, but it's something I want to learn well, having brushed against it at university in the '80s, and having played with Linux somewhat.
I think you will experience a sizeable learning curve. You will be working with Unix and C as it stood around 1975 and that is substantially different from what it was in the 80’s. That said, I know from personal experience that it is an intriguing journey and certainly not impossible to do.
> Some help would be nice, but more generally, is anyone on this list more than vaguely familiar with LSX, or 6th Edition itself?
Many on this list are familiar with 6th edition. The best way to learn the internals of 6th edition is the “Lions’ book”:
https://www.amazon.com/Lions-Commentary-Unix-John/dp/1573980137
Coming from today’s perspective (or a 1980’s one), you will find the following key challenges:
- The version of C used for 6th edition is different from the 1980’s. Amongst other things the syntax of the assignment operators changed (not += but =+), the syntax for initialisation changed (not 'int a = 3', but 'int a 3’), the ‘long’ datatype (32 bit on a PDP-11) did not exist, the ‘void’ keyword did not exist, structs could not be assigned, passed or returned (only pointers to structs), etc.
- The stdio library did not exist yet, in its place there was the ‘portable i/o library’. This may be the hardest part to get used to.
- The file system was 16-bit based throughout. This has implications for stat(), lseek() did not exist (its precursor seek() used additional whence values to move the file pointer in 512 byte increments), etc.
When it comes to LSX, there are a few people who have experience with it on the this list (that I know of - there may be many more).
First of all, Heinz Lycklama, the original creator of LSX, appears to read this list from time to time.
Second, Leonid Broukhis and Serge Vakulenko (who managed to recover the LSX sources 20 years ago) might be reading the list. They took the trouble to port LSX to the Soviet BK-0010 computer, an LSI-11 type system some 15 years ago:
https://github.com/sergev/bkunix
You can stand on their shoulders, as they already took the trouble to convert the kernel source from 1975 C to 1980’s C and to create a stdio compatible library for it; they are using the 2.11BSD C compiler, which generates tighter code than the 1975 compiler — hence they could squeeze a bit more functionality in.
Third, I found the BK-0010 port some 5 years ago and used that as base to create a version that would run on a small TI990 clone:
http://www.stuartconner.me.uk/mini_cortex/mini_cortex.htm
This work later evolved into a stock 6th edition kernel and is now a curious mix of stuff dating from 1975 to 1985.
Your main challenge will be that neither the BK-0010 work nor my work will run on your hardware as-is. I think you have two possible paths forward. The first is to learn C and the library as it stood in 1975, the second is to take the BK-0010 code and to make it run on a stock LSI-11 again.
The title of the fmt man page in v9 was "ultra-simple text formatter".
Gnu dropped the "ultra" in favor of AI. Sometimes it does a pretty
job. Sometimes it messes up my typing style. Always it produces a
an apparently wavering right margin, as it assigns a separate
"optimal" line length to each paragraph. It's hard to imagine how
this command could stray from classic Unix simplicity and
intelligibility, but Gnu pulled it off.
Doug
re: main.
i was surprised not to see any mention of the entry keyword reserved but, i believe, never used in early c. it is listed in k&r ed1.
i always assumed this was to allow the author to choose an alternative to main() for the program’s entry point, but we all know what assumption is...
-Steve
