Hello,
Unix V8 has some code for Chaosnet support. There is a small hobbyist
Chaos network going with Lispm, PDP-10, PDP-11, and Berkeley Unix nodes.
Is there anyone who would be interested in trying to see if the V8 code
is in a workable state, and get it running?
Best regards,
Lars Brinkhoff
Re-subject'd as this part of the conversation diverges.
Found the quote that I was thinking of when I said that:
https://yarchive.net/comp/bsd.html
"Research Unix 8th Edition started from (I think) BSD 4.1c, but with enormous amounts scooped out and replaced by our own stuff." - Dennis Ritchie
The "I think" adds some murkiness for sure. There's definitely a good chunk of code from 4BSD. Compare init, getty, locore.c (as opposed to .s in V7 back). Heck, even the main.c between the two kernels are more similar to each other than V7. I would almost opt towards calling that being rebased on 4BSD rather than V7 with bits and pieces of BSD added. I could see it being more beneficial to start with 4BSD and tack on necessary Bell bits rather than take V7/32V and try and shoehorn in the VM implementation for VAX.
The 4.1cBSD copy on the archive does appear to be pretty different, so in terms of raw comparison, I suspect the basis is 4BSD rather than 4.1cBSD. I don't know that we have a clean copy of 4.1BSD gold, I'd be interested to see if the structure of the source code changed between 4.1 and 4.1c, as 4.1c does exhibit the new organization by the BSD folks, 4BSD still shows folders like cmd, lib, and so on.
Not trying to be combative by any means, but I've been doing a bit of research lately into when V8 was snapped from BSD and where Bell and Berkeley then diverged from that last major confluence, especially with a focus on init and other early stages of userland.
- Matt G.
------- Original Message -------
On Friday, July 15th, 2022 at 1:51 AM, Paul Ruizendaal via TUHS <tuhs(a)tuhs.org> wrote:
> > Message: 6
> > Date: Thu, 14 Jul 2022 17:51:39 +0000
> > From: segaloco segaloco(a)protonmail.com
> >
> > Given V8 being rebased on 4(.1?)BSD, I suspect the path of least resistance would be to just start grafting V8 code onto the working 4.1BSD.
>
>
> I doubt that V8 is "rebased on 4(.1?)BSD": in my understanding it ported some code from 4xBSD, but it is a different code base.
>
> As I currently understand it, the V8 kernel:
>
> - is a further development from 32V
> - retains the code organisation of the V5..32V versions
> - adds virtual memory code from BSD
> - adds select() from BSD
>
> and then adds all the V8 innovation on top of that (streams, file system switch, virtual proc file system, networking, remote file system, support for the Blit terminal, etc.)
>
> In particular in the area of networking the V8 kernel is organised quite differently from the 4xBSD kernel, including the Chaosnet driver (i.e. it is streams based).
>
> Paul
> From: Lars Brinkhoff
> There is a small hobbyist Chaos network going
What encapsulation are they using to transmit CHAOS packets (over the
Internet, I assume)? I know there was an IP protocol number assigned for
CHAOS (16.), but I don't recall if there was ever a spec? (Which is kind of
amusing, since in 'Assigned Numbers', the person responsible for 16. is ....
me! :-)
There was a spec for encapsulating IP in CHAOS, and that actually _was_
implemented at MIT BITD; it was used for a while to get IP traffic to a Unix
machine (V7, IIRC) over on main campus, at a stage when only CHAOS hardware
(very confusing that the same name was applied to hardware, and a protocol
suite) ran across to main campus from Tech Square.
> From: Grant Taylor
> I wonder if there is an opportunity for something that pretends to be
> the remote side locally, sends the data via some other
> non-latency-sensitive protocol to a counter part where the counter part
> pretends to be the near side.
Let's think through the details. The near-end 'invisibility box' (let's call
it) is going to have to send acks to the original source machine, otherwise
that will time out, abort the connection, etc. The originating machine is its
own thing, and this behaviour can't be controlled/stopped.
(This, BTW, shows a key difference between 'local' and 'across network'
modes, a recent topic here; in a situation where two distinct machines are
cooperating across a network, the other machine is its own entity, and can't
be expected/guaranteed to do anything in particular at all.)
In addition, the near-end invisibility box is going to have to keep a copy of
each packet, until the destination machine sends an ack to the invisibility
box - because if the packet is lost, the invisibility box is going to have to
retransmit it. (The original source is not going to - it's already gotten an
ack, so as far as it's concerned, that packet is done and dusted.) And the
near-end invisibility box is also going to have to have to have a time-out
timer, so that when the ack isn't seen, it will know to retransmit the packet.
There's no point to _also_ sending the acks on to the originating machine;
they won't do anything useful, and might just confuse it.
So, let's see now: the near-end invisibility box buffers the packet, looks
for an ack, times out when it doesn't see it, re-transmits the packet - that
sounds familiar? Oh, right, it's a reliable connection.
And presumably there's an invisibility box at the far end too, so the same
can happen for any data packets the destination machine sends.
The only question is whether, when doing the detailed design, there's any
point to having the destination machine's acks sent to the near-end
invisibility box - or just use them at the far-end invisibility box. (I.e.
create three reliable connections: i) a CHAOS connection originating
machine<->near-end invisibility box; ii) {whatever} near-end invisibility
ox<->far-end invisibility box; iii) CHAOS far-end invisibility box<->original
destination machine - and glue them together.)
That is in some sense simpler than creating an extra-ordinary mechanism to
have a 'helper' box in the middle of the connection (to terminate the CHAOS
connection from the original machine, and have another CHAOS connection, but
with an enhanced time-out mechanism which can cope with larger RTT's, from
there to the original destination); and the same in the other direction.
The amusing thing is that the CHAOS protocol stack actually already had
something very similar to this, BITD. If one were sitting at a machine that
only had CHAOS, and one wanted to (say) TELNET to an ARPANET host, there was
a CHAOS service which ARPANET hosts on the CHAOSNET provided: open a CHAOS
connection to that serrver, and it would open an NCP connection to one's
intended ultimate destination, and glue the byte streams together. (The
ultimate destination was passed as data over the CHAOS connection, when
opening it.)
Noel
> Message: 6
> Date: Thu, 14 Jul 2022 17:51:39 +0000
> From: segaloco <segaloco(a)protonmail.com>
>
> Given V8 being rebased on 4(.1?)BSD, I suspect the path of least resistance would be to just start grafting V8 code onto the working 4.1BSD.
I doubt that V8 is "rebased on 4(.1?)BSD": in my understanding it ported some code from 4xBSD, but it is a different code base.
As I currently understand it, the V8 kernel:
- is a further development from 32V
- retains the code organisation of the V5..32V versions
- adds virtual memory code from BSD
- adds select() from BSD
and then adds all the V8 innovation on top of that (streams, file system switch, virtual proc file system, networking, remote file system, support for the Blit terminal, etc.)
In particular in the area of networking the V8 kernel is organised quite differently from the 4xBSD kernel, including the Chaosnet driver (i.e. it is streams based).
Paul
> If I can get this working, I have a long laundry list of modifications and
> experiments that I want to run with LSX, but as it stands, this is where I
> am stuck at.
Once upon a time there was a Soviet home computer that was based on the PDP-11, the BK0010:
https://en.wikipedia.org/wiki/Electronika_BK
(it is actually mostly a copy of the Terak 8510a -- https://en.wikipedia.org/wiki/Terak_8510/a )
The guy that found the surviving floppy with LSX source code (Leonid Broukhis) for the PDP-11 immediately ported it to the BK0010 and created a fair amount of infrastructure around it:
https://github.com/ignusius/bkunix
He used the 2.11BSD toolchain to create a cross-compiler. As that compiler had progressed significantly from the 5th Edition era compiler, the kernel became smaller and he could squeeze some stripped functionality back in. The repo says that the code there still works on a normal PDP-11.
I’ve never communicated with Leonid, but maybe Warren has contact details for him. Also, the person who created LSX unix (Heinz Lycklama) is reading this list -- but of course it has been 40+ years since he last touched the code.
Note that LSX only holds one process in core and swaps other processes (NPROC = 3) out to floppy. It reportedly took several hours for the Terak to self-compile LSX from source. At one point I added debugger support to my own port of LSX to a TI-990 with just floppies ... let’s just say, now I understand deeply why the original Unix debug interface was an improvement opportunity :^)
> From: Gavin Tersteeg
> I spent a lot of time getting UNIX V6 working on my PDP-11/23 system.
> It took a lot of tinkering with the kernel and drivers to make it work
> in the way I wanted to
You must have made a lot of changes for it to take "a lot of tinkering".
Bringing V6 up on the /23 has been done several times, and when I did
it, it only took about 2 dozen lines of code in about 2 files. What all
did you wind up changing?
> From my research, it seems like there were two different UNIX variants
> that could run on a system like this. These variants were LSX and
> MINI-UNIX. MINI-UNIX seems to require a decent mass-storage device like
> a RK05 and some porting to work on an 11/03, while LSX is designed to
> work on exactly the hardware specs that I have on hand.
Bringing up MINI-UNIX on the /03 has been done at least twice; once
historically (now lost, AFAIK), and again recently:
http://ana-3.lcs.mit.edu/~jnc/tech/unix/Mini/Mini.html
I'm not sure what you're basing the "MINI-UNIX seems to require a decent
mass-storage device like a RK05" on - it should run as well on whatever
you're running LSX on as LSX does.
I haven't run LSX myself, but from what I've seen, the only significant
difference between the two is that LSX will run with less main memory than
MINI-UNIX (which really kind of needs 56KB; LSX you can probably get away
with 40KB).That was a significant issue when the LSI-11 was originally
released, but these days one has to really work to have a QBUS PDP-11 with
less than 56KB.
> my EIS-less 11/03
EIS chips can be found on eBait for not much money (I just bought a couple
myself), and it's worth investing in one, so on can dispense with the
emulator, which takes real memory for which a better use can be found.
> The first issue is that the C compiler will randomly spit out a "0:
> Missing temp file" when attempting to compile something. This is
> annoying, but circumventable by just running the same command over and
> over until it works.
Schaeffer's Law (from Larry Niven): anything you don't understand
might be dangerous. I'd track down why this is happening.
Noel
It would be really appreciated if people replying to messages like this would
take 10 minutes (or so - that's about how lonfg it took me to find the actual
answer to this person's question) to do some research, instead of just
replying off the top of their heads with whatever they happen to think they
know.
> From: Gavin Tersteeg
> I can't seem to get the kernel to actually link together once
> everything is compiled. When the final "ld -X" is executed, I always
> get the following errors:
> "Undefined:
> _end
> _edata
> _decmch"
The first two are automagically defined by the linker after a successful
read-through of the files+libraries, i.e. when then are no un-defined
symbols. Ignore them; they will go away when you fix the problem.
The real issue is the missing 'decmch'. That apparently comes from decfd.c,
which I assume is the DEC floppy disk driver. Depending on the setting of the
EIS conditional compilation flag (a different one for C files, from the
PDP-11 assembler files, please note - and I haven't worked out what its
definitiion means; whether if defined, it means the machine _does_ have the
EIS, or _does not_x), it will be called for.
'decmch' is in low.s (rather oddly; that usualy holds just interrupt vectors
and interrupt toeholds), conditionally assembled on:
.if DEC
.if EIS-1
The first line presumably adds it if there _is_ a DEC floppy disk, the second
I don't know _for sure_ the sense of (although I'm guessing that EIS=1 means
there _is_ an EIS chip, so this line says 'assemble if there it _not_ an EIS
chip').
Although you'd think that whatever calculation it is doing, it would need to
do if there's an EIS chip or not, so with an EIS chip it must calculate it
some other way; you'll have to read decfd.c and see how it works.
Note that you'll have to make sure the EIS flags (note plural) are set
to the same sense, when compiling the C and assembler files...
Let me send this off, and I'll reply to some other points in a
separate message.
Noel
Hello, and greetings!
I guess as this is my first post here, I should give some background on
what I have been working on. Last summer I spent a lot of time getting UNIX
V6 working on my PDP-11/23 system. It took a lot of tinkering with the
kernel and drivers to make it work in the way I wanted to, but in the end I
was left with a system that ran well enough to do some demonstrations at
VCFMW.
This year I want to do more stuff with 1970s era UNIX, but now with even
more technical restrictions. I have had a Heathkit H-11 (consumer grade
PDP-11/03) for a while now, and I have been looking for something
interesting to do with it. From my research, it seems like there were two
different UNIX variants that could run on a system like this. These
variants were LSX and MINI-UNIX. MINI-UNIX seems to require a decent
mass-storage device like a RK05 and some porting to work on an 11/03, while
LSX is designed to work on exactly the hardware specs that I have on hand.
So on to the actual issues I am having at the moment: I have put together a
SIMH instance to get the ball rolling in building a kernel that will boot
on my EIS-less 11/03, but I am having significant difficulty actually
getting the kernel to build. The first issue is that the C compiler will
randomly spit out a "0: Missing temp file" when attempting to compile
something. This is annoying, but circumventable by just running the same
command over and over until it works. The second issue, however, is much
more of a road block for me. I can't seem to get the kernel to actually
link together once everything is compiled. When the final "ld -X" is
executed, I always get the following errors:
"
Undefined:
_end
_edata
_decmch
"
(This is from the build script found in the "shlsx" file)
https://minnie.tuhs.org/cgi-bin/utree.pl?file=LSX/sys/shlsx
I am assuming that this is some sort of issue with the object file
orderings, but I simply do not know enough about V6 ld to properly debug
this issue. I am hoping that somebody here has already run into this issue,
and knows what I am doing wrong.
If I can get this working, I have a long laundry list of modifications and
experiments that I want to run with LSX, but as it stands, this is where I
am stuck at.
Thank you,
Gavin
The interpretation of a string of addresses separated by commas and/or
semicolons was already defined in the v1 man page for ed.
Ed was essentially a stripped-down version of Multics qed. The latter
was originally
written by Ken. Unfortunately the "Multics Condensed Guide" online at
multicians.org describes how strings of addresses were interpreted
only by canonical examples for the various editing requests.
I have no specific memory of semicolons in qed. I have a vague
recollection that semicolons originated in ed, however you should put
no trust in this. Maybe Ken remembers.
Doug
