TUHS

tuhs@tuhs.org

2 participants
6532 discussions

Tenth Edition: /usr/include + get it running

by Warren Toomey

All, I've just had an e-mail from someone to say that the two 10th Edition versions we now have in the Unix Archive are missing /usr/include: ----- Forwarded message from someone ----- /usr/include is missing from both Dan's and Norman's archive. Here it is (with a README). The timestamp on these files is: -rw-r--r-- 1 root staff 307 Sep 3 1997 README -rw-r--r-- 1 root staff 829440 Sep 3 1997 r70include.tar ----- End forwarded message ----- I've put these files into http://www.tuhs.org/Archive/Distributions/Research/Norman_v10/ Now that we have 9th Edition up and running, it would be good to see 10th Edition also up and running. I know there are people out there who can help with this, so this is a call out for help and for volunteers. Cheers, Warren P.S The UUCP project is now up to 23 sites: https://github.com/DoctorWkt/4bsd-uucp/blob/4.3BSD/uucp.png

8 years, 3 months

TUHS GitHub org

by Cory Smelosky

All, I have created a TUHS-related github org to store: 1). UUCP-related patched software 2). patched/maintained c-news 3). forks et al of newsreaders Largely just to give a central locatiom. Usual disclaimers apply...if you want me to delete the org/change name/transfer ownership/etc just shoot me an email. https://github.com/TUHS -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects

8 years, 3 months

Re: [TUHS] Pi, samuel, cin and 8th, 9th, 10th Edition Unix

by Doug McIlroy

> If anyone has any information about 'samuel' or 'cin', > I would be delighted to hear from him or her. cin appears in the v9 and v10 manuals. Thus if the program is found in the wild, there should be no compunction about adding it to the tuhs archive. Doug

8 years, 3 months

Re: [TUHS] [Uucp] bringing systems up

by Cory Smelosky

Due to having an actual NSA VAX...I think I should get NSAVAX ;) Sent from my iPhone > On Mar 30, 2017, at 23:13, Dave Horsfall via Uucp <uucp(a)minnie.tuhs.org> wrote: > >> On Thu, 30 Mar 2017, Kurt H Maier via Uucp wrote: >> >> kremvax and moskvax are online. What's the policy on uucp.map entries >> for hosts that never really existed in the first place? > > Hmmm... I wouldn't mind having "kgbvax" in that case (I've relinquished > "utzoo" to Henry Spencer himself). Or possibly "ciavax" or "fbivax"... > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

8 years, 3 months

Pi, samuel, cin and 8th, 9th, 10th Edition Unix

by Noel Hunt

I was just the other day apprised of the fact that Warren Toomey had finally got permission to make public sources from Eight, Ninth and Tenth Edition Unix. It was Paul McJones from the Software Preservation Group who made me aware of this because some months ago I was in touch with him in regard to the status of source for 'pads/pi' which is on the SPG website. That was donated by Bjorn Stroustrup in 2004 I believe, as an example of a large C++ project, along with sources for 'cfront'. I myself have been working on pads/pi in a desultory fashion since 1990 when I left the Basser Department of Computer Science at the University of Sydney; we had an Eighth Edition licence, hence source code, and all of the blit/jerq utilities. I ported 'pads' to the Plan9 graphics model many years ago, and finally started to port 'pi' to Solaris 11 a couple of years ago. This works in a rudimentary fashion, but needs a Dwarf interface. Given that Bjorn Stroustrup released this code long ago (a much later version than what I had), I daresay there are no problems with its publication. I have, however, also worked on 'samuel' and ported its functionality to the Plan9 'sam'. 'samuel' does not appear in any of the archives that Wareen Toomey has made available, so I am wondering what its status may be. It was written by John Puttress at the labs in the late '80s, when he was apparently working under Ted Kowalski. Ted Kowalski is also a 'person of interest' because he wrote 'cin', the C interpreter, an interface to which exists in 'samuel'. Ted Kowalski unfortunately passed away some years ago and no-one seems to know where the source is. It again, isn't in any of the archives that Wareen Toomey has been able to make available. If anyone has any information about 'samuel' or 'cin', I would be delighted to hear from him or her. Bruce Ellis, who wrote 'cyntax', told me that he worked on 'cin' a lot (in the '90s I think, when he worked at Bell Labs) but it was succeeded by something named 'vice', about which I can find no information. Again, I would be grateful for any information about this. Regards, Noel Hunt

8 years, 3 months

Re: [TUHS] Ethernet in /dev (was Re: Were all of you.. Hippies?)

by Norman Wilson

Joerg Schilling: This is done on a UNIX implementation that uses STREAMS. SVr4 is such a UNIX. ====== I know that SVr4 has STREAMS (somewhat more elaborate than the original stream I/O system, but the same principles), and knew (though I'd forgotten) that Ethernet devices are stream-capable. I did an implementation of the late lamented Coraid's AoE protocol that took advantage of that. Somewhat like the Research IP implementation, in fact: there was an AoE line discipline to be pushed onto an Ethernet device, coupled to devices in /dev/dsk and /dev/rdsk. But is IP done that way in SVr4 (or at least in Solaris, its most-visible descendant)? I had the impression that the IP stack was more like the BSD one, with everything coupled together within the kernel and a fundamentally socket interface. I've never actually looked at the code, though. Norman Wilson Toronto ON

8 years, 3 months

Re: [TUHS] Release of 8th, 9th and 10th Editions Unix

by Norman Wilson

Arnold: > Well, I'll take credit for pushing Norman yet again. :-) ARGGH. That should have been Well, I'll take credit for pushing Warren ... ^^^^^^ ===== I confess I didn't notice the fumble the first time. But in fact Warren has had the dubious pleasure of pushing me for something more than once. So just think of it as another level of indirection. Norman Wilson Toronto ON

8 years, 3 months

Re: [TUHS] Ethernet in /dev (was Re: Were all of you.. Hippies?)

by Norman Wilson

Ron Natalie: It's a violation of the network layering concept to require or even allow the user to bind the application data streams to a physical device. ===== Oh, come on. If you mean an applications programmer shouldn't have to wallow in low-level network details, I agree. That's one of the reasons I think the socket interface now standard in nearly every UNIX is an abomination. It reminds me of the binary data structures you had to assemble just to open a file in TOPS-10, only ten times worse. But if you mean it's a violation of layering for the kernel to expose the pieces and let user-mode code to the work, I strongly disagree. By that argument, the very idea of inetd is an abomination. Possibly even the ifconfig command. And don't even get the hypothetical you started on microkernels. User-mode code for device drivers or file systems? Outrageous violation of layering! Send in the New Jersey Inquisition!! Or perhaps you misunderstand how it all works. Device files for Ethernet devices, /dev/ip*, and so on are like those for disk devices: you could allow anyone to read and write them, but in practice you probably wouldn't: you'd restrict access to the super-user and perhaps a special group to admit some sort of privilege reduction (like the group allowed to read disks on some systems, or to read /dev/kmem). That parts of the stack are assembled in user mode is a feature, not a bug. The one glaring flaw, as I said, is that no permissions are checked when pushing a stream line discipline onto a file. I think that happened because when Dennis first wrote the code, he was thinking about modules to implement canonical-tty semantics, or to invoke the very-different Datakit networking model. It's a fundamental flaw, though. I have had thoughts about fixing it, but never enough time nor enough motivation. (My technical mind is pretty much filled up by what I am paid to do these days; I haven't done much hobby computing in years.) Norman Wilson Toronto ON

8 years, 3 months

Ethernet in /dev (was Re: Were all of you.. Hippies?)

by Norman Wilson

Josh Good: Which brings up a question I have: why didn't UNIX implement ethernet network interfaces as file names in the filesystem? Was that "novelty" a BDS development straying away from AT&T UNIX? ====== Remember that UNIX has long been a family of systems; it's risky to make blanket statements! The following is from memory; I haven't looked at this stuff for a while and am a few kilometers from my manuals as I type this. I can dig out the complete story later if anyone wants it; for now, this is just the flavour and the existence proof. Research UNIX, once it supported Ethernet at all, did so using devices in /dev; e.g. /dev/qe0[0-7] were the conventional names for the first DEQNA/DELQA device on a MicroVAX. There were eight subdevices per physical device, each a channel that might receive datagrams of a particular 16-bit type, programmed by an ioctl. To set up what we now call an IP interface, one did the following: a. Open an unused channel for the proper Ethernet physical device. (I think the devices were exclusive- open to make this easier: open /dev/qe00, then qe01, and so on until one succeeds.) b. Issue the ioctl to set the desired datagram type, usually 0x800. c. Push the IP stream line discipline onto the open file. d. Issue an ioctl to inform that IP instance of its address and netmask. Now datagrams of the specified type arriving on that device are fed to the IP subsystem, and the IP subsystem uses the IP address and mask and possibly other information to decide which datagrams to route to that IP instance, which sends them out that physical device. I forget how ARP and Ethernet encapsulation fit in. I know that they were someone more naive early on, and that in the 10/e systems I can now admit I have running at home I made things a bit smarter and less brittle. But that's the basic architecture. So how does one actually make, say, a TCP connection? Another layer of the same sort: There are devices /dev/ipX, served by an IP device driver that is part of the IP subsystem. Originally minor device X was hard-connected to IP protocol X; I later changed that to be ioctl-configured as well. To make TCP usable: a. Open /dev/ip6 (old school), or find an unused /dev/ipX (again they are exclusive-open) and configure it to accept protocol 6. b. Push the TCP stream line discipline onto the open file. c. There are probably things one could then configure, but I don't remember them offhand. To make a TCP call, open an unused /dev/tcpNN device; write something to it (or maybe it was an ioctl) with the desired destination address; wait for an error or success. On success, writes to the file descriptor send to the network, encapsulated as a TCP stream; reads receive. To receive a TCP call, open an unused /dev/tcpNN device, and write something (or ioctl) to say `I want to listen on this local port.' Then read the file. When a call arrives, you will read a message saying who's calling, and what /dev/tcpXX device you should open to accept the call. Notice the general scheme: for both TCP and IP (and there was a primitive UDP at one point, but it has fallen out of use on my systems), the protocol implementation comprises: 1. A line discipline: push it onto devices that will transport your data. 2. A device driver: use those devices to send and receive calls. The two are inextricably coupled inside the operating system, of course. There are all sorts of unfortunate details surrounding communications; e.g. the TCP code knows it is talking to IP, and constructs datagrams with partly-filled-in IP headers. (It is not clear one can do better than that in practice, because the protocols themselves really are linked, but I still think it's unfortunate.) On the other hand, that the junctions between plumbing are accessible makes some things very simple. I wrote a PPP implementation in user mode, with no kernel changes: to plug itself into IP, it just pushed the IP line discipline onto one end of a pipe, and read and wrote datagrams on the other. I later extended it to PPPoE by having it open an Ethernet device set to the proper datagram types (there is one for data and another for connection setup). On the other other hand, there are no permissions on stream line disciplines, so an untrustworthy person (if I allowed such on my systems) could push the IP line discipline onto his own pipe and send whatever datagrams he liked. This is decidedly a flaw. Those familiar with the original stream-system implementation have already spotted a lesser flaw: the file descriptor with IP pushed on (or TCP, or whatever) must remain open; when it is closed, everything shuts down. In practice it is usually useful to have a daemon listening to that file anyway; that's a good way for the system to report errors or confusion. In practice, TCP incalls and outcalls all went through a special daemon anyway, so that programs didn't have to be full of TCP-specific crap; that's what Dave Presotto's `connection server' is all about. Norman Wilson Toronto ON

8 years, 3 months

Re: [TUHS] 8th Edition Research Unix on SIMH

by Jason Stevens

Thanks for the hints, and whatnot... I got v8 running! > ---------- > From: Tim Newsham > Sent: Wednesday, March 29, 2017 7:50 AM > To: David du Colombier > Cc: The Eunuchs Hysterical Society > Subject: Re: [TUHS] 8th Edition Research Unix on SIMH > > Would be great if someone scripted it up to make it dog-simple. > Here's how I did it for v6: http://www.thenewsh.com/~newsham/myv6/README > (I should do this, but I'm not sure I'll have time in the near future). > > On Tue, Mar 28, 2017 at 8:58 AM, David du Colombier < 0intro(a)gmail.com> > wrote: > > > Here are my notes to run 8th Edition Research Unix on SIMH. > > http://9legacy.org/9legacy/doc/simh/v8 > > These notes are quite raw and unpolished, but should be > sufficient to get Unix running on SIMH. > > Fell free to use, improve and share. > > -- > David du Colombier > > > > > > -- > > Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | > thenewsh.blogspot.com >

8 years, 3 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS