[TUHS] 2.9bsd with networking on 18-bit possible?
clemc at ccc.com
Wed Dec 12 02:26:41 AEST 2018
IIRC is how UNET worked for V7.
FWIW: UNE T was the original product from 3COM and somewhere I have the
package with the Postmark as the 32nd of December - because 3Com had a
requirement to ship by the end of the year to their VCs. At the last
hours, Greg Shaw and Bruce Borden ran into a problem, so it shipped a day
late [they obviously got their money].
On Tue, Dec 11, 2018 at 11:17 AM Noel Chiappa <jnc at mercury.lcs.mit.edu>
> > From: Clem Cole <clemc at ccc.com>
> > This is why I suggested that if you really want telnet and ftp to the
> > PDP-11, you might be better off moving the networking stack out of
> > kernel
> Really, the answer is that I need to get off my @ss and put the MIT V6+
> up (I have all the files, just need to get a round tuit).
> It has TCP/IP, but is it not all crammed into the kernel. And unlike the
> BBN V6, it doesn't do TCP as a single process to which all the other
> client/server processes talk via IPC.
> Instead, the only thing in the kernel is inbound demuxing, and minimal
> processing. (IIRC, outbound packets are copied into kernel buffers; an
> version of the networking interface driver actually did do inbound and
> DMA directly from buffers in the user's process, but only one process
> could use
> the network interface at a time.)
> The TCP code was a library that was built into the user process which did
> server/client applications. (The servers which supported login, like FTP,
> needed to run as root, like the ordinary login, setuid'ing to the entered
> user-id.) I don't remember if we supported server Telnet, but I think we
> did. So we must have added PTY's of some sort, I'll have to check.
> Since the TCP was in the user process, we actually had a couple of
> ones, depending on the application. Dave Clark had done a quick-n-dirty
> TCP on
> the Alto (in BCPL) which was only good for things like user Telnet, not for
> applications that sent a lot of data. We ported that one for the first
> TCP; we
> later did a 'high-speed bulk data' TCP, used for FTP, etc. I don't remember
> which one SMTP used.
> The whole thing worked _really_ well. Alas, I don't think anyone else
> up on it.
> The kernel code is not that large, it should even run on a /40, without
> overlays (although the number of disk buffers would probably get hit). And
> since the TCP is in user processes, it could all get swapped out, so it
> run OK on machines without that much physical memory.
> The issue is going to be that it will need a new network interface driver,
> since I think the only driver ever done for it was for Pronet. And now we
> back to the 'what interfaces are available' question. Doing a DEC driver
> allow use of DEQNA's and DELQA's on QBUS machines, which would be optimal,
> since they are common. And people could bring up Unix with TCP/IP on
> But we'd have to add ARP (which I would do as a process, with only the
> IP->Ether address mapping table stored in the kernel). I wrote a really
> ARP for the C Gateway that could easily be used for that.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the TUHS