TUHS

tuhs@tuhs.org

28 participants
6556 discussions

Re: [TUHS] Early Internet work (Was: History of select(2))

by Johnny Billquist

On 2017-01-16 03:00, jnc(a)mercury.lcs.mit.edu (Noel Chiappa) wrote: > > From: Johnny Billquist > > > Like I pointed out, RFC760 lacks ICMP. > > So? TCP will work without ICMP. True. However, IP and UDP will have issues. > > Which also makes one question how anyone would have known about IPv4 in > > 1978. > > Well, I can assure you that _I_ knew about it in 1978! (The decision on the v4 > packet formats was taken in the 5th floor conference room at 545 Tech Sq, > about 10 doors down from my office!) > > But everyone working on TCP/IP heard about Version 4 shortly after the June, > 1978 meeting. Over a year before any documents said anything about it. This is where I have problems. :-) > > Also, first definition of TCP shows up in RFC 761 > > If you're speaking of TCPv4 (one needs to be precise - there were also of > course TCP's 1, 2, 2.5 and 3, going back to 1974), please see IEN-44. (Ignore > IEN's -40 and -41; those were proposals for v4 that got left by the wayside.) That is a very good point. I've been talking v4 all the time (both for IP and TCP). Like I said, I'm sure people were doing networking protocols and stuff earlier, but it wasn't the TCP/IP we know and talk about today, and you just reaffirmed this. And yes, the TCP/IP we know today did not come out of a blue sky. Of course it is based on earlier work. (Just do you don't have to go on about that again.) > > So yes, I still have problems with claims that they had it all running > > in 1978. > > I never said we had it "all" running in 1978 - and I explicitly referenced > areas (congestion, addressing/routing) we were still working on over 10 years > later. > > But there were working implementations (as in, they could exchange data with > other implementations) of TCP/IPv4 by January 1979 - see IEN 77. But not TCP4 then. And thus, not interoperable with an implementation today, and interoperable in general being a rather floating and moving target, as you had several imvompatible TCP versions, using different protocol numbers, and several incompatible IP versions. > (I'll never forget that weekend - we were in at ISI on Saturday, when it was > normally closed, and IIRC we couldn't figure out how to turn the hallway > lights on, so people were going from office to office in the gloom...) Fun times, I bet. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

8 years, 7 months

Re: [TUHS] Early Internet work (Was: History of select(2))

by jnc＠mercury.lcs.mit.edu

> (Check the minutes in the IEN's, that's probably the best source of data > on progress of the various implementations.) Another place to look is Internet Monthly Reports and TCP-IP Digests (oh, I see you've seen those, I see a reference to one). I have this distinct memory of Dave Clark mentioning the Liza Martin TCP/IP for Unix in one of the meeting report publihed as IENs, but a quick look didn't find it. Noel

8 years, 7 months

Re: [TUHS] Early Internet work (Was: History of select(2))

by Paul Ruizendaal

On 14 Jan 2017, at 17:41 , Michael Kjörling wrote: > On 13 Jan 2017 10:13 +0100, from pnr(a)planet.nl (Paul Ruizendaal): >> over on the internet history mailing list. > > Interesting. Care to give me a pointer toward it? That mailing list is here: http://mailman.postel.org/mailman/listinfo/internet-history On 14 Jan 2017, at 23:02 , Johnny Billquist wrote: > IMPs did not talk IP, just for the record. Yes, this is true of course. The software of the IMP was resurrected from printouts some time ago: http://walden-family.com/impcode/ > The problem is that all the RFCs are available, and they are later than this. The ARPAnet existed in 1979, but it was not using TCP/IP. If you look at the early drafts of TCP/IP, from around 1980-1981, you will also see that there are significant differences compared to the TCP/IP we know today. There was no ICMP, for example. Error handling and passing around looked different. Once again: yes. When exactly was the TCP/IP specification completed? That is an issue where reasonable people can hold different opinions. What software first implemented this on Unix? Here too reasonable people can hold different opinions. Below my take on this, based on my current understanding (and I keep repeating that I'm learning new things about this stuff almost every day and please advise if I'm missing things). Development of TCP/IP The specification that became TCP/IP apparently finds its roots in 1974, and it is gradually developed over the next years with several trial implementations. By March 1977 we get to TCP2 and more trials. Next it would seem that there was a flurry of activity from January to August 1978, resulting in specifications for TCP4 (IEN54 and IEN55). Then, up to March more implementations follow, as documented in IEN98. With those implementations tested, also for interoperability, more changes to the protocol and implementations follow and I guess by April 1981 (RFC777) we reach a point where things are specified to a level where implementations would interoperate with today's implementations. This is not where it stops, 'modern' congestion control only goes back to the late 80's (see for instance Craig Partridge http://www.netarch2009.net/slides/Netarch09_Craig_Partridge.pdf, it is an interesting read). Early Unix code bases (1) The Mathis/Haverty stack In 1977 Jim Mathis at SRI writes a "TCP2.5" stack in PDP11 assembler, running on the MOS operating system (for the LSI11). In 1978 Haverty is assigned to take this stack and make it run on V6 Unix. He builds a kernel with ports, await and capac to achieve this. It is a mixed success (see http://mailman.postel.org/pipermail/internet-history/2016-October/004073.ht…) but he maintains it through 1978 and 1979 as a skunkworks project and the code eventually supports TCP4 (as defined in IEN54/55). The source has survived in Jack Haverty's basement as a printout, but it is not online. As far as I know know, this the first TCP/IP on Unix (a tie with the Wingfield implementation, and only if one accepts IEN54/55 as 'TCP/IP'). (2) The Grossman (DTI) stack IEN98 mentions a TCP3 stack done for Network Unix (by then called ENFE/INFE) in 1978 by DTI / Gary Grossman. I don't currently have information about that implementation. As at March 1979 it did not appear to support TCP4. (3) The Wingfield/Cain stack In 1978 BBN / Michael Wingfield, was commissioned by DCEC / Ed Cain to write a TCP4 tack in C for Unix V6. As it stood in March 1979 this code supported IEN54/55 with the AUTODIN II security extensions that heralded back to 1975. It is a partial implementation: it does not support IP fragmentation and it has a simplistic approach to incoming out-of-order packets (drop everything until the right one arrives). However, it worked and kept being maintained by Ed Cain, who by October 1981 has added support for ICMP and GGN (https://www.rfc-editor.org/rfc/museum/tcp-ip-digest/tcp-ip-digest.v1n1.1) He is still supporting it as late as 1985 (https://www.rfc-editor.org/rfc/museum/tcp-ip-implementations.txt.1) As far as I know know, only the March 1979 code survives. I'm currently retyping it, about halfway through. I'm not sure what compiler it was written for: it uses longs, but apparently this is still somewhat broken (with comments in the source amounting to 'this WTF necessary to work around compiler bugs'); at the same time it also uses old-style assignments ('=+' instead of '+='). Could this be "typesetter C"? The code feels like it might be based on earlier work, for instance the BBN BCPL implementation for TENEX a few years earlier, but that is pure speculation. It could also be that Wingfield was new to C and bringing habits from other languages with him. Once all done, I'll ask Michael about it. I'm on thin ice here, but my current guess would be that the 5,000 line code base would need some 500 lines of new code to make it interoperable with today's implementations. From the above I would support the moniker "first TCP/IP in C on Unix" as claimed by UCLA, either for the March 1979 version if one takes the view that '90% modern' is good enough, or for the October 1981 version if support for RFC777 is the benchmark. In the latter view it beats the Gurwitz stack by about a month or two. However, it is not a full implementation of the specifications. (4) The Gurwitz stack Last in the list of candidates is the Rob Gurwitz stack for BSD4.1 (see IEN168), started in January 1981. It is a full implementation of the protocols that looks like it was done from scratch (as confirmed by Gurwitz and Haverty) and consolidates the earlier learnings. In my opinion, it is the first implementation where the source code has a distinct 'early unix smell' (please excuse the phrase), arguably more so that the later Joy code. The first iterations of the code don't support (the as yet non-existent) RFC777. By November 1981 there is a beta distribution tape that does, and this code looks to interoperate with modern TCP/IP implementations as-is. If the benchmark is a full implementation interoperating with today's code, the first TCP/IP on Unix would I think be the Gurwitz stack. Possibly it is the first TCP/IP in that definition on any OS. Note that this is also where TCP/IP and Network Unix join back up [but this view might change as I learn more about the Grossman / DTI version]: the Gurwitz code uses an API closely based on that of UoI's Network Unix and the provided user land programs (Telnet, FTP, MTP, etc.) appear ports from that code base (or perhaps from a BBN development of the UoI work). === In any case, I think it is fair to say that TCP/IP as we know it today did not drop from the sky in 1981. There was a vast amount of prior work done in the second half of the 70's on a variety of hardware and operating systems, experience that all feeded into the well known RFC's. One thing that I'm unclear about is why all this Arpanet work was not filtering more into the versions of Unix done at Bell Labs. The folks involved were certainly aware of each other and the work that was going on. With universities the cost of 'always on' long distance lines may have been too great, but within Bell Labs that would have been less of an issue and there is a clear link with the core business of the Bell System. Would anybody have some background on that? Paul

8 years, 7 months

Re: [TUHS] Early Internet work (Was: History of select(2))

by jnc＠mercury.lcs.mit.edu

> From: Johnny Billquist > Like I pointed out, RFC760 lacks ICMP. So? TCP will work without ICMP. > Which also makes one question how anyone would have known about IPv4 in > 1978. Well, I can assure you that _I_ knew about it in 1978! (The decision on the v4 packet formats was taken in the 5th floor conference room at 545 Tech Sq, about 10 doors down from my office!) But everyone working on TCP/IP heard about Version 4 shortly after the June, 1978 meeting. > Also, first definition of TCP shows up in RFC 761 If you're speaking of TCPv4 (one needs to be precise - there were also of course TCP's 1, 2, 2.5 and 3, going back to 1974), please see IEN-44. (Ignore IEN's -40 and -41; those were proposals for v4 that got left by the wayside.) > So yes, I still have problems with claims that they had it all running > in 1978. I never said we had it "all" running in 1978 - and I explicitly referenced areas (congestion, addressing/routing) we were still working on over 10 years later. But there were working implementations (as in, they could exchange data with other implementations) of TCP/IPv4 by January 1979 - see IEN 77. (I'll never forget that weekend - we were in at ISI on Saturday, when it was normally closed, and IIRC we couldn't figure out how to turn the hallway lights on, so people were going from office to office in the gloom...) Noel

8 years, 7 months

Re: [TUHS] History of select(2)

by jnc＠mercury.lcs.mit.edu

> From: Johnny Billquist <bqt(a)softjar.se> > And RFC791 is dated September 1981. Yes, but it had pretty much only editorial changes from RFC-760, dated January 1980 (almost two years before), and from a number of IEN's dated even earlier than that (which I'm too lazy to paw through). > So I have this problem with people who say that they implemented TC/IP > in 1978 for some reason. If you look at IEN-44, June 1978 (issued shortly after the fateful June 15-16 meeting, where the awful 32-bit address decision was taken), you will see that the packet format as of that date was pretty much what we have today (the format of addresses kept changing for many years, but I'll put that aside for now). > Especially if they say ... it was working well in heterogeneous > networks. TCP/IP didn't work "well" for a long time after 1981 - until we got the congestion control stuff worked out in the late 80's. And IIRC the routing/ addressing stuff took even longer. > I don't think it's correct to say that it was TCP/IP, as we know it > today. Why not? A box implementing the June '78 spec would probably talk to a current one (as long as suitable addresses were used on each end). > It was either some other protocol (like NCP) or some other version of > IP, which was not even published as an RFC. Nope. And don't put too much weight on the RFC part - TCP/IP stuff didn't start getting published as RFC's until it was _done_ (i.e. ready for the ARPANet to convert from NCP to TCP/IP - which happened January 1, 1983). All work prior to TCP/IP being declared 'done' is documented in IEN's (very similar documents to RFC's, distributed by the exact same person - Jon Postel). Noel

8 years, 7 months

Re: [TUHS] History of select(2)

by Johnny Billquist

On 2017-01-13 18:57, Paul Ruizendaal <pnr(a)planet.nl> wrote: > > On 12 Jan 2017, at 4:54 , Clem Cole wrote: > >> The point is that while I have no memory of capac(), but I can confirm that I definitely programmed with the empty() system call and Rand ports on a v6 based kernel in the mid-1970s and that it was definitely at places besides Rand themselves. > Thank you for confirming that. If anybody knows of surviving source for these extensions I'd love to hear about it. Although the description in the implementation report is clear enough to recreate it (it would seem to be one file similar to pipe.c and a pseudo device driver similar in size to mem.c), original code is better. It is also possible that the code in pipe.c was modified to drive both pipes and ports -- there would have been a lot of similarity between the two, and kernel space was at a premium. > >> [...] confirming something I have been saying for few years and some people have had a hard time believing. The specifications for what would become IP and TCP were kicking around the ARPAnet in the late 1970s. > My understanding is that all RFC's and IEN's were available to all legit users of the Arpanet. By 1979 there were 90 nodes (IMP's) and about 200 hosts connected. I don't get the impression that stuff was always easy to find, with Postel making a few posts about putting together "protocol information binders". Apparently nobody had the idea to put all RFC's in a directory and give FTP access to it. They were, and still are. And I suspect Clem is thinking of me, as I constantly question his memory on this subject. The problem is that all the RFCs are available, and they are later than this. The ARPAnet existed in 1979, but it was not using TCP/IP. If you look at the early drafts of TCP/IP, from around 1980-1981, you will also see that there are significant differences compared to the TCP/IP we know today. There was no ICMP, for example. Error handling and passing around looked different. IMPs did not talk IP, just for the record. RFC760 defines IPv4, and is dated January 1980. It refers to some previous documents that describe IP, but they are not RFCs. Also, if you look at RFC760, you will see that errors were supposed to be handled through options in the packet header, and that IP addresses, while 32 bits, were just split into 8 bits for network number, and 24 bits for host. There were obviously still some work needed before we got to what people think on IPv4 today. Anyone implementing RFC760 would probably not work at all with an IPv4 implementation that exist today. > I am not sure how available this stuff was outside the Arpanet community. I think I should put a question out about this, over on the internet history mailing list. > > As an aside: IMHO, conceptually the difference between NCP and TCP wasn't all that big. In my current understanding the big difference was that NCP assumes in-order, reliable delivery of packets (as was the case between IMP's) and that TCP allows for unreliable links. Otherwise, the connection build-up and tear-down and the flow control were similar. See for instance RFC54 and RFC55 from 1970. My point is: yes, these concepts were kicking around for over a decade in academia before BSD. Not sure if BSD is a good reference point. Much stuff was not actually done on Unix systems at all, if you start reading machine lists in the early RFCs. Unix had this UUCP thingy, that they liked. ;-) BSD and networking research came more to the front doing all the refinements over the years. Anyway, yes, for sure TCP did not come out of the void. It was based on earlier work. But there are some significant differences between TCP/IP and NCP, which is why you had the big switch day. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

8 years, 7 months

Re: [TUHS] 2.11BSD cross compiling update

by Nick Downing

I see, no I had not realized that code is still in use, I would have thought it had been replaced by a whole lot of POSIX bloat. Admittedly the 2.11BSD ctime/asctime/localtime/timezone stuff is simplistic and doesn't address complicated cases but it's good enough. However I have to resist the temptation to improve or update stuff in 2.11BSD, I went down that path many times (with the Makefiles project for instance) and because everything is interdependent you always introduce more problems and get deeper and deeper enmeshed. In order to stay in control I only fix essentials and apply a rule of minimal change, period. This applies until I have a baseline that builds exactly the same binary system image as the native build. Then I might proactively improve parts of the system but I will not do it reactively if you follow. As I see it the zic behaviour is not a bug since time_t is 32 bits on 2.11BSD and has no unreasonable values, and localtime() is BSD not POSIX compliant and is not allowed to return NULL. cheers, Nick On 14/01/2017 6:53 AM, "Random832" <random832(a)fastmail.com> wrote: On Fri, Jan 13, 2017, at 12:57, Nick Downing wrote: > I then ended up doing a fair bit of re-engineering, how this came > about was that I had to port the timezone compiler (zic) to run on the > Linux cross compilation host, since the goal is eventually to build a > SIMH-bootable disk (filesystem) with everything on it. This was a bit > involved, it crashed initially and it turned out it was doing > localtime() on really small and large values to try to figure out the > range of years the system could handle. On the Linux system this > returns NULL for unreasonable time_t values which POSIX allows it to > do. Hence the crash. It wasn't too obvious how to port this code. (But > whatever I did, it had to produce the exact same timezone files as a > native build). You know that the timezone file format that it uses is still in use today, right? There's extra data at the end in modern ones for 64-bit data, but the format itself is cross-platform, with defined field widths and big-endian byte order. What do you get when you compare the native built timezone files with one from your linux host's own zic? It *should* only differ by the version number in the header [first five bytes "TZif2" vs "TZif"] and the 64-bit section, if you're giving it the same input files. And I bet you could take the current version of the code from IANA and, if it matters to you, remove the parts that output the 64-bit data. If nothing else, looking at the modern code and the version in 2.11BSD side-by-side will let you backport bug fixes. (Note: Technically, the version present in most Linux systems is a fork maintained with glibc rather than the main version of the code from IANA)

8 years, 7 months

2.11BSD cross compiling update

by Nick Downing

So I got a fair bit further advanced on my 2.11BSD cross compiler project, at the moment it can make a respectable unix tree (/bin /usr etc) with a unix kernel and most software in it. I unpacked the resulting tarball and chrooted into it on a running SIMH system and it worked OK, was a bit rough around the edges (missing a few necessary files in /usr/share and that kind of thing) but did not crash. I haven't tested the kernel recently but last time I tested it, it booted, and the checksys output is OK. I then ended up doing a fair bit of re-engineering, how this came about was that I had to port the timezone compiler (zic) to run on the Linux cross compilation host, since the goal is eventually to build a SIMH-bootable disk (filesystem) with everything on it. This was a bit involved, it crashed initially and it turned out it was doing localtime() on really small and large values to try to figure out the range of years the system could handle. On the Linux system this returns NULL for unreasonable time_t values which POSIX allows it to do. Hence the crash. It wasn't too obvious how to port this code. (But whatever I did, it had to produce the exact same timezone files as a native build). So what I ended up doing was to port a tiny subset of 2.11BSD libc to Linux, including its types. I copied the ctime.c module and prefixed everything with "cross_" so there was "cross_time_t" and so forth, and "#include <time.h>" became "#include <cross/time.h>", in turn this depends on "#include <cross/sys/types.h>" and so on. That way, the original logic worked unchanged. I decided to also redo the cross compilation tools (as, cc, ld, nm, ranlib and so on) using the same approach, since it was conceptually elegant. This involved making e.g. "cross_off_t" and "struct cross_exec" available by "#include <cross/a.out.h>", and obviously the scheme extends to whatever libc functions we want to use. In particular we use floating point, and I plan to make a "cross_atof()" for the C compiler's PDP-11-formatted floating-point constant handling, etc. (This side of things, like the cross tools, was working, but was not terribly elegant before). So then I got to thinking, actually this is an incredibly powerful approach. Instead of just going at it piecemeal, would it not be easier just to port the entire thing across? To give an example what I mean, the linker contains code like this: if (nund==0) printf("Undefined:\n"); nund++; printf("%.*s\n", NNAMESIZE, sp->n_name); It is printing n_name from a fixed-size char array, so to save the cost of doing a strncpy they have used that "%.*s" syntax which tells printf not to go past the end of the char array. But this isn't supported in Linux. I keep noticing little problems like this (actually I switched off "-Wformat" which was possibly a bad idea). So with my latest plan this will actually run the 2.11BSD printf() instead of the Linux printf(), and the 2.11BSD stdio (fixing various other breakage that occured because BUFSIZ isn't 512 on the Linux system), and so on. What I will do is, provide a low level syscalls module like cross_open(), cross_read(), cross_write() and so on, which just redirect the request into the normal Linux system calls, while adjusting for the fact that size_t is 16 bits and so forth. This will be really great. In case it sounds like this is over-engineering, well bear in mind that one knotty problem I hadn't yet tackled is the standalone utilities, for instance the 2.11BSD tape distribution contains a standalone "restor" program which is essentially a subset of the kernel, including its device drivers, packaged with the normal "restor" utility into one executable that can be loaded off the tape. It was quite important to me that I get this ported over to Linux, so that I can produce filesystems, etc, at the Linux level, all ready to boot when I attach them to SIMH. But it was going to be hugely challenging, since compiling any program that includes more than the most basic kernel headers would have caused loads of conflicts with Linux's kernel headers and system calls. So the new approach completely fixes all that. I did some experiments the last few days with a program that I created called "xify". What it does is to read a C file, and to every identifier it finds, including macro names, C-level identifiers, include file names, etc, it prepends the sequence "x_". The logic is a bit convoluted since it has to leave keywords alone and it has to translate types so that "unsigned int" becomes "x_unsigned_int" which I can define with a typedef, and so on. Ancient C constructs like "register i;" were rather problematic, but I have got a satisfactory prototype system now. I also decided to focus on 4.3BSD rather than 2.11BSD, since by this stage I know the internals and the build system extremely intimately, and I'm aware of quite a lot of inconsistencies which will be a lot of work to tidy up, basically things that had been hurriedly ported from 4.3BSD while trying not to change the corresponding 2.8~2.10BSD code too much. Also in the build system there are quite a few different ways of implementing "make depend" for example, and this annoys me, I did have some ambitious projects to tidy it all up but it's too difficult. So a fresh start is good, and I am satisfied with the 2.11BSD project up to this moment. So what will happen next is basically once I have "-lx_c" (the "cross" version of the 4.3BSD C library) including the "xified" versions of the kernel headers, then I will try to get the 4.3BSD kernel running on top of Linux, it will be a bit like User-Mode Linux. It will use simulated network devices like libpcap, or basically just whatever SIMH uses, since I can easily drop in the relevant SIMH code and then connect it up using the 4.3BSD kernel's devtab. The standalone utilities like "restor" should then "just work". The cross toolchain should also "just work" apart from the floating point issue, since it was previously targeting the VAX which is little-endian, and the wordsize issues and the library issues are taken care of by "xifying". Very nice. The "xifying" stuff is in a new repository 43bsd.git at my bitbucket (user nick_d2). cheers, Nick

8 years, 7 months

History of select(2)

by Warren Toomey

Also, I came across this history of select(2) a while back: https://idea.popcount.org/2016-11-01-a-brief-history-of-select2/ Cheers, Warren

8 years, 7 months

Re: [TUHS] Early Internet work (Was: History of select(2))

by jnc＠mercury.lcs.mit.edu

> From: Paul Ruizendaal >> On 12 Jan 2017, at 4:54 , Clem Cole wrote: >> The specifications for what would become IP and TCP were kicking around >> ... in the late 1970s. The whole works actually started considerably earlier than that; the roots go back to 1972, with the formation of the International Packet Network Working Group - although that group went defunct before TCP/IP itself was developed under DARPA's lead. I don't recall the early history well, in detail - there's a long draft article by Ronda Hauben which goes into it in detail, and there's also "INWG and the Conception of the Internet: An Eyewitness Account" by Alexander McKenzie which covers it too. By 1977 the DARPA-led effort had produced several working prototype implementations, and TCP/IP (originally there was only TCP, without a separate data packet carriage layer) were up to version 3. > My understanding is that all RFC's and IEN's were available to all legit > users of the Arpanet. Yes and no. The earliest distribution mechanism (for the initial NCP/ARPANet work) was hardcopy (you can't distribute things over the 'net before you have it working :-), and in fact until a recent effort to put them all online, not all RFC's were available in machine-readable form. (I think some IEN's still aren't.) So for many of them, if you wanted a copy, you had to have someone at ISI make a photocopy (although I think they stocked them early on) and physically mail it to you! > Apparently nobody had the idea to put all RFC's in a directory and give > FTP access to it. I honestly don't recall when that happened; it does seem obvious in retrospect! Most of us were creating document in online text systems, and it would have been trivial to make them available in machine-readable form. Old habits die hard, I guess... :-) > I think I should put a question out about this, over on the internet > history mailing list. Yes, good idea. > As an aside: IMHO, conceptually the difference between NCP and TCP > wasn't all that big. Depends. Yes, the service provided to the _clients_ was very similar (which can be seen in how similar the NCP and TCP versions of thing like TELNET, FTP, etc were), but internally, they are very different. > In my current understanding the big difference that was NCP assumes > in-order, reliable delivery of packets ... and that TCP allows for > unreliable links. Yes, that's pretty accurate (but it does mean that there are _a lot_ of differences internally - re-transmissions, etc). One other important difference is that there's no flow control in the underlying network (something that took years to understand and deal with properly). > yes, these concepts were kicking around for over a decade in academia > before BSD. TCP/IP was the product of a large, well-organized, DARPA-funded and -led effort which involved industry, academic and government players (the first two, for the most part, DARPA-funded). So I wouldn't really call it an 'academic' project. Noel

8 years, 7 months

VFS: confusion (and an end)

by Berny Goodheart

Thanks Warren for saving me to sort out the confusion. I am sorry I started it in the first place. On Tue, Jan 10, 2017 at 11:20 AM, Joerg Schilling <schily(a)schily.net <mailto:schily@schily.net>> wrote: > …. Note that > this list is very similar to that in the early part of his book on System V > internals. Having having just removed the dust off my old copy of TMGE, it is interesting that the list I wrote here is very similar to what I wrote back in 1993. Just goes to show, Alzheimer’s hasn’t got me yet ;)

8 years, 7 months

VFS: confusion (and an end)

by Warren Toomey

Ok, the story so far. Berny wrote: Here's the breakdown of SVR4 kernel lineage as I recall it. ... From SunOS: vnodes VFS Dan Cross wrote: > VFSSW <=== NO, this is from SunOS-4 Surely Berny meant the file system switch here, which could have come from early system V, but originated in research Unix (8th edition?). Joerg Schilling wrote: It is rather a part of the VFS interface that has first been completed with SunOS-3.0 in late 1985. And this is where the confusion starts. Does "It" refer to FSS or VFS? I've just looked through some sources. The file system switch was in SysVR3: uts/3b2/sys/mount.h: /* Flag bits passed to the mount system call */ #define MS_RDONLY 0x1 /* read only bit */ #define MS_FSS 0x2 /* FSS (4-argument) mount */ VFS was in SunOS 4.1.4: sys/sys/vfs.h: struct vfssw { char *vsw_name; /* type name string */ struct vfsops *vsw_ops; /* filesystem operations vector */ }; And VFS is in SysVR4: uts/i386/sys/vfs.h: typedef struct vfssw { char *vsw_name; /* type name string */ int (*vsw_init)(); /* init routine */ struct vfsops *vsw_vfsops; /* filesystem operations vector */ long vsw_flag; /* flags */ } vfssw_t; Interestingly, the "filesystem operations vector" comment also occurs in FreeBSD 5.3, NetBSD-5.0.2 and OpenBSD-4.6. Look for vector here: http://minnie.tuhs.org/cgi-bin/utree.pl?file=FreeBSD-5.3/sys/sys/mount.h http://minnie.tuhs.org/cgi-bin/utree.pl?file=NetBSD-5.0.2/sys/compat/sys/mo… http://minnie.tuhs.org/cgi-bin/utree.pl?file=OpenBSD-4.6/sys/sys/mount.h Larry wrote: System Vr3 had something called the file system switch which is what Berny is talking about. SunOS had virtual file system layer (VFS) and that would be one of things ported to SVr4. which is consistent with everybody else. So now that we have consistency, let's move on. Cheers, Warren

8 years, 7 months

the guy who brought up SVr4 on Sun machines

by Berny Goodheart

I have been trolling these many threads lately of interest. So thought I should chip in. "SVr4 was not based on SunOS, although it incorporated many of the best features of SunOS 4.x”. IMHO this statement is almost true (there were many great features from BSD too!). SunOS 5.0 was ported from SVR4 in early 1991 and released as Solaris 2.0 in 1992 for desktop only. Back in the late 80s, Sun and AT&T partnered development efforts so it’s no surprise that SunOS morphed into SVR4. Indeed it was Sun and AT&T who were the founding members of Unix International…with an aim to provide direction and unification of SVR4. I remember when I went to work for Sun (much later in 2003), and found that the code base was remarkably similar to the SVR4 code (if not exact in many areas). Here’s the breakdown of SVR4 kernel lineage as I recall it. I am pretty sure this is correct. But I am sure many of you will put me right if I am wrong ;) From BSD: TCP/IP C Shell Sockets Process groups and job Control Some signals FFS in UFS guise Multi groups/file ownership Some system calls COFF From SunOS: vnodes VFS VM mmap LWP and kernel threads /proc Dynamic linking extensions NFS RPC XDR From SVR3: .so libs revamped signals and trampoline code VFSSW RFS STREAMS and TLI IPC (Shared memory, Message queues, semaphores) Additional features in SVR4 from USL: new boot process. ksh real time extensions Service access facility Enhancements to STREAMS ELF

8 years, 7 months

Re: [TUHS] the guy who brought up SVr4 on Sun machines

by jnc＠mercury.lcs.mit.edu

> I wonder if >pdd ... was in any way any inspiration for /proc? That may have been a bit too cryptic. "pdd" ('process directory directory') was a top-level directory in the Multics filesystem which contained a directory for each process active in the system; each directory contained data (in segments - roughly, 'files', but Multics didn't have files because it was a single-level store system) associated with the process, such as its kernel- and user-mode (effectively - technically, ring-0 and ring-4) stacks, etc. So if a process was sitting in a system call, you could go into the right directory in >pdd and look at its kernel stack and see the sequence of procedure calls (with arguments) that had led it to the point where it blocked. Etc, etc. Noel

8 years, 7 months

Re: [TUHS] Rje / sna networking

by Rudi Blom

>Date: Wed, 11 Jan 2017 02:16:26 +0000 >From: Steve Simon <steve(a)quintile.net> >To: tuhs(a)tuhs.org >Subject: [TUHS] Rje / sna networking >Message-ID: <05DECAED-065A-4520-805A-D86CF1596A01(a)quintile.net> >Content-Type: text/plain; charset=us-ascii >Casual interest, >Anyone ever used RJE from SYS-III - IBM mainframe remote job entry >System? I started on Edition 7 on an interdata so I am (pretty much) too young >for that era, unless I am fooling myself. >-Steve In the 90sh DEC in Europe had a number of products on top of SCO UNIX 3.2V4.2 calling DECadvantage (from the German part of former Philips Information Systems). Included were an SNA environment with 3270 display/print, 3770/RJE, and APPC. I've used RJE for downloading daily reports in one of the banks here in Thailand. Long time ago though. Still have various sample scripts I put together that time.

8 years, 7 months

/proc aka the guy who brought up SVr4 on Sun machines

by Doug McIlroy

> /proc came from research Indeed it did. > /proc was done by Roger at AT&T (maybe USL). I recall him telling me that > he was not the original author though and that it came from PWB. Roger Faulkner's /proc article, recently cited in tuhs, begins with acknowledgment to Tom Killian, who originated /proc in research. (That was Tom's spectacular debut when he switched from high-energy physics, at Argonne IIRC, to CS at Bell Labs.) doug

8 years, 7 months

BSD job control, aka the guy, etc

by Lars Brinkhoff

I asked: > I wonder where the inspiration for the Unix job control came from? In > particular, I can't help but notice that Control-Z does something very > similar in the PDP-10 Incompatible Timesharing System. Jim Kulp answered: > The ITS capabilities were certainly part of the inspiration. It was a > combination of frustrations and gaps in UNIX with some of those > features found in ITS that resulted in the final package of features.

8 years, 7 months

Rje / sna networking

by Steve Simon

Casual interest, Anyone ever used RJE from SYS-III - IBM mainframe remote job entry System? I started on Edition 7 on an interdata so I am (pretty much) too young for that era, unless I am fooling myself. -Steve

8 years, 7 months

Re: [TUHS] Unix stories, Stephen Bourne and IF-FI in C code

by Norman Wilson

Doug McIlroy: There was some pushback which resulted in the strange compromise of if-fi, case-esac, do-done. Alas, the details have slipped from memory. Help, scj? ==== do-od would have required renaming the long-tenured od(1). I remember a tale--possibly chat in the UNIX Room at one point in the latter 1980s--that Steve tried and tried and tried to convince Ken to rename od, in the name of symmetry and elegance. Ken simply said no, as many times as it took. I don't remember who I heard this from; anyone still in touch with Ken who can ask him? Norman Wilson Toronto ON

8 years, 7 months

NFS aka the guy who brought up SVr4 on Sun machines

by Doug McIlroy

Reputed origins of SVR4: > From SunOS: > ... > NFS And, sadly, NFS is still with us, having somehow upstaged Peter Weinberger's RFS (R for remote) that appeared at the same time. NFS allows one to add computers to a file system, but not to combine the file systems of multiple computers, as RFS did by mapping uids: NFS:RFS::LAN:WAN. Doug

8 years, 7 months

Re: [TUHS] the guy who brought up SVr4 on Sun machines

by jnc＠mercury.lcs.mit.edu

> From: Chet Ramey > /proc was done by Roger at AT&T (maybe USL). I recall him telling me > that he was not the original author though and that it came from PWB. > The original implementation was done by Tom Killian for 8th Edition. I wonder if >pdd (which dates to somewhere in the mid-60's, I'm too lazy to look the exact date up) was in any way any inspiration for /proc? Noel

8 years, 7 months

Ksh and SVR4

by pechter＠gmail.com

Wasn't ksh SVR4... It was in the Xelos sources @Concurrent Computer which was an SVR2 port. Xelos didn't do paging but the source in 87 or 88 or so had ksh in it. I. built it for SVR4 on my Xelos 3230 back in the day. Bill Sent from my android device.

8 years, 7 months

Re: [TUHS] the guy who brought up SVr4 on Sun machines

by Berny Goodheart

> On 10 Jan 2017, at 16:16, pechter(a)gmail.com wrote: > > Wasn't msg SVR4... It was in the Xelos sources @Concurrent Computer which was an SVR2 port. Xelos didn't do paging but the source in 87 or 88 or so had ksh in it. > > I. built it for SVR4 on my Xelos 3230 back in the day. msgs goes back as far as SVR2. > > Bill > > Sent from my android device. > > -----Original Message----- > From: Berny Goodheart <berny(a)berwynlodge.com> > To: tuhs(a)minnie.tuhs.org > Sent: Tue, 10 Jan 2017 10:12 > Subject: [TUHS] the guy who brought up SVr4 on Sun machines > > I have been trolling these many threads lately of interest. So thought I should chip in. > > "SVr4 was not based on SunOS, although it incorporated > many of the best features of SunOS 4.x”. > > IMHO this statement is almost true (there were many great features from BSD too!). > SunOS 5.0 was ported from SVR4 in early 1991 and released as Solaris 2.0 in 1992 for desktop only. > Back in the late 80s, Sun and AT&T partnered development efforts so it’s no surprise that SunOS morphed into SVR4. Indeed it was Sun and AT&T who were the founding members of Unix International…with an aim to provide direction and unification of SVR4. > I remember when I went to work for Sun (much later in 2003), and found that the code base was remarkably similar to the SVR4 code (if not exact in many areas). > > Here’s the breakdown of SVR4 kernel lineage as I recall it. I am pretty sure this is correct. But I am sure many of you will put me right if I am wrong ;) > > From BSD: > TCP/IP > C Shell > Sockets > Process groups and job Control > Some signals > FFS in UFS guise > Multi groups/file ownership > Some system calls > COFF > > From SunOS: > vnodes > VFS > VM > mmap > LWP and kernel threads > /proc > Dynamic linking extensions > NFS > RPC > XDR > > From SVR3: > .so libs > revamped signals and trampoline code > VFSSW > RFS > STREAMS and TLI > IPC (Shared memory, Message queues, semaphores) > > Additional features in SVR4 from USL: > new boot process. > ksh > real time extensions > Service access facility > Enhancements to STREAMS > ELF > > > > >

8 years, 7 months

Re: [TUHS] the guy who brought up SVr4 on Sun machines

by jnc＠mercury.lcs.mit.edu

> From: Berny Goodheart > From BSD: > Process groups and job Control The intermediate between V6 and V7 which ran on several MIT machines (I think it was an early PWB - I should retrieve it and make it available to the Unix archive, it's an interesting system) had 'process groups', but I don't know if the concept was the same as BSD process groups. Noel

8 years, 7 months

Re: [TUHS] Unix stories, Stephen Bourne and IF-FI in C code

by jnc＠mercury.lcs.mit.edu

> From: Tony Finch > The other classic of Algol 68 literature No roundup of classic Algol 68 literature would be complete without Hoare's "The Emperor's Old Clothes". I assume everyone here has read it, but on the off-chance there is someone who hasn't, a copy is here: http://zoo.cs.yale.edu/classes/cs422/2014/bib/hoare81emperor.pdf and I cannot recommend it more highly. Noel

8 years, 7 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