From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id a99ee668 for ; Wed, 28 Aug 2019 04:06:00 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 1047D9BCBF; Wed, 28 Aug 2019 14:05:59 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id C9F559BC42; Wed, 28 Aug 2019 14:05:43 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id A4C559BC42; Wed, 28 Aug 2019 14:05:41 +1000 (AEST) Received: from mcvoy.com (mcvoy.com [192.169.23.250]) by minnie.tuhs.org (Postfix) with ESMTPS id 1E7C19BC35 for ; Wed, 28 Aug 2019 14:05:41 +1000 (AEST) Received: by mcvoy.com (Postfix, from userid 3546) id 28DE535E0A8; Tue, 27 Aug 2019 21:05:40 -0700 (PDT) Date: Tue, 27 Aug 2019 21:05:40 -0700 From: Larry McVoy To: Rob Pike Message-ID: <20190828040540.GT13570@mcvoy.com> References: <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net> <20190827024511.GU13570@mcvoy.com> <20190827145556.GD13570@mcvoy.com> <20190827224002.GB15511@mcvoy.com> <20190827225955.GC15511@mcvoy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Subject: Re: [TUHS] [SPAM] Re: If not Linux, then what? X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" I could be wrong but that's my memory. What he told me was streams was for line disciplines for tty drivers. That's what I know but you were there, I was not. I'm pretty confused because what Dennis said to me was that he did not think streams would work for networking, he thought they made sense for a stream but not for a networking connection because that had multiple connections coming up through a stream. I'm happy to be wrong but can you talk more about what he was thinking? There is no way that I'm saying you are wrong, you are you, I just want to learn. If there is a way that streams made sense for networking I'd like to see that. My experience with STREAMS is that they sucked really hard for networking. My guess is I need to go learn about mpx, I don't know that. On Wed, Aug 28, 2019 at 01:22:33PM +1000, Rob Pike wrote: > I find it hard to believe what you remember Dennis saying. The point of > dmr's streams was to support networking research in the lab and avoid the > myriad bugs of the mpx interface by stepping around them completely. > > Perhaps it's out of context. > > -rob > > > On Wed, Aug 28, 2019 at 9:00 AM Larry McVoy wrote: > > > streams were OK but Dennis himself told me he didn't intend them for > > networking. They were a simple mechanism for pushing line disciplines > > onto tty drivers. > > > > I can't remember exactly what he said, this was back in ~1988 or so > > and I was talking to him about the STREAMS stuff. He wasn't very > > happy with it and I'm pretty sure he said something like streams > > weren't design to mux multiple sources or network connections. > > I think he sort of grudgingly gave credit that they made it work > > but he seemed to think that it was twisting streams more than they > > should be twisted. > > > > On Wed, Aug 28, 2019 at 08:46:35AM +1000, George Michaelson wrote: > > > oh maybe I meant "streams" not "STREAMS" I always got confused if the > > > original ritchie spec was upper or lower case. Charles Forsyth coded > > > it into the York Uni Vaxen, worked fine. I left shortly after to do > > > stuff at UCL, it only came back into my life when at UQ in Australia > > > we got an ICL "certified" SYSV host and along side dead technology > > > like RFS up it popped (I think ICL had coded an OSI stack we were > > > testing) > > > > > > -G > > > > > > On Wed, Aug 28, 2019 at 8:40 AM Larry McVoy wrote: > > > > > > > > Wait, are you arguing for STREAMS over sockets? Dear god, please no. > > > > Have you ever used STREAMS (not Ritchies streams, those were OK)? > > > > I have. I ported Lachman's STREAMS based TCP/IP stack twice, once > > > > to a long since defunct super computer called the ETA-10 and then > > > > to SCO Unix. I've got way more STREAMS experience than most people > > > > and I can tell you that sockets are WAY WAY better. I get the "it > > > > should have just been file I/O" except that I don't. I tried to > > > > write a library that let you open up /net/tcp/$host:$port and do > > > > I/O like it was a file descriptor. That works for a lot of stuff > > > > but I ran into problems quickly. A networking connection is not > > > > a file handle. You can make some stuff work but I couldn't figure > > > > out how to do all of it. You end up having to do ioctls to handle > > > > the stuff that doesn't fit well into the file system name space. > > > > I think plan 9 did this sort of thing, maybe Rob can prove me wrong > > > > or remember where it didn't match. > > > > > > > > I do know that STREAMS came back to Solaris, some VP inked a shitty > > > > deal with Lachman and bought the rights to the stack. It was slow > > > > as molasses in the winter and customers absolutely hated it. Sun > > > > got Mentat to redo it for perf but customers still hated it, they > > > > understood sockets, everyone else had sockets, they wanted sockets > > > > and they got them. Sun put them back and nobody ever asked about > > > > STREAMS again. > > > > > > > > On Wed, Aug 28, 2019 at 08:30:01AM +1000, George Michaelson wrote: > > > > > BSD, but with the original STREAMS semantics, not sockets. > > > > > > > > > > DARPA did us no favours accepting sockets in place of simple file I/O > > > > > semantics for networks. > > > > > > > > > > Newcastle connection put the namespace into > > > > > /.../remote-part/path/to/thing which I felt was also good. > > > > > > > > > > So for me, 7 -> BSD -> got worse for some values of worse > > > > > > > > > > On Wed, Aug 28, 2019 at 12:56 AM Larry McVoy wrote: > > > > > > > > > > > > On Mon, Aug 26, 2019 at 11:14:45PM -0400, Arthur Krewat wrote: > > > > > > > On 8/26/2019 10:45 PM, Larry McVoy wrote: > > > > > > > > Which was that the page cache is > > > > > > > >*the* cache. There is nothing else. > > > > > > > Yeah, I re-read what you wrote a few times after I replied, and > > realized > > > > > > > what you meant ... eventually ;) > > > > > > > > > > > > I might be making too big of a deal about it. mmap semantics > > mattered > > > > > > a lot when SMPs first showed up and main memory was small. It > > meant > > > > > > that you could have multiple CPUs seeing and working on the same > > chunk > > > > > > of data at the same time. > > > > > > > > > > > > It's very similar to way that IOMMUs are exposed to user space > > these > > > > > > days, enabling virtual machines direct access to the I/O devices. > > > > > > > > > > > > ZFS breaks that model, the data is all in the ARC and if you mmap > > > > > > it they have to bcopy the data out of the ARC, into the page cache > > > > > > and now they have a consistency problem, you could modify stuff > > > > > > via mmap or write and they have to manage that. > > > > > > > > > > > > That consistency problem is the main reason that Sun almost > > completely > > > > > > killed the buffer cache (it still was used for inodes and > > directories > > > > > > but that was it). That consistency problem is a pain in the rear, > > > > > > all sorts of race conditions and it tended to bit rot. > > > > > > > > > > > > Jeff and Bill are smart people so I suspect they got it right but > > I'm > > > > > > still stunned that they took such an architecturally bad approach. > > > > > > And even more stunned that the oversight people approved it. There > > > > > > is zero chance that the Sun I worked at would have allowed that. > > > > > > > > > > > > --lm > > > > > > > > -- > > > > --- > > > > Larry McVoy lm at mcvoy.com > > http://www.mcvoy.com/lm > > > > -- > > --- > > Larry McVoy lm at mcvoy.com > > http://www.mcvoy.com/lm > > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm