This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Tue Apr 23 16:17:49 2024 Received: from orchard.washtenaw.cc.mi.us (orchard.washtenaw.cc.mi.us [198.111.176.4]) by herbie.ucs.indiana.edu (8.6.12/8.6.12) with ESMTP id NAA13227 for ; Thu, 20 Jun 1996 13:39:19 -0500 Received: from vger.rutgers.edu by orchard.washtenaw.cc.mi.us (8.6.10/2.3) with ESMTP id OAA14469; Thu, 20 Jun 1996 14:24:59 -0400 Received: by vger.rutgers.edu id <106249-7188>; Thu, 20 Jun 1996 14:07:39 -0500 From: Alan Cox Message-Id: <199606201553.QAA13202@snowcrash.cymru.net> Subject: Re: 2.2.0 wishlist To: Mark.Hemment@uniplex.co.uk Date: Thu, 20 Jun 1996 16:53:14 +0100 (BST) Cc: alan@cymru.net, inr-linux-kernel@ms2.inr.ac.ru, linux-kernel@vger.rutgers.edu In-Reply-To: from "Mark.Hemment@Uniplex.Co.UK" at Jun 20, 96 03:57:51 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk > Am I missing the point? We are talking about kernel STREAMS? > That _very_ good idea of modularising functionality? The idea > that makes writing device-drivers easier. (well, they don't make > it any harder). That allows protocols stacks to sit nicely > on top of each other. That allows module re-use (PUSH an encrypting > module into your down/up stream). That allows multiplexers (de-muxs) > to be easily written :) That makes your performance reminiscent of a PC running DOS. > That can help in multi-threading a kernel (multiple-thread the > STREAMS correctly, and the drivers/modules follow - well, almost, yes?). No > That can be used to pass data directly between a device's dual-ported > memory up into user's process. Ah, those lovely 'cloning' devices. No > Being able to pass pipes between unrealted processes.... You can do that with sockets > a few faults, and nasty kludges in some places to make them usable > as sockets. I cannot agree they are 'too slow'. All the people who I count as networking experts say streams are much too slow. People like Van Jacobson: I quote a couple ... "I agree with your conclusion that STREAMS stink. Anyone who's measured the code reaches the same conclusion. It's widely believed that the esigners' of STREAMS were all former COBOL programmers taken off writing long distance billing programs for AT&T and ordered to learn C and turn v7 Unix into System-V. " -- Van Jacobson to Mike Neumann And Dennis Ritchie on what they did to his elegant v8 streams.. "the idea loses something when it's shouted" > IMHO, STREAMS do bring a benefit to user space, but the largest > gain is within the kernel (they make it a much more friendlier place > to live, and code). Trying emulating them in user space sounds > strange to me. I guess you were stating that it is theoritically > possible? Yes. The kernel's business isnt being a friendly place. The kernel's business is doing things for user space as fast as is possible as efficiently as possible. If we wanted it friendly we'd write it in basic 8) Streams for example has strict layering. The memory subsystem of a modern machine makes strict layering the wrong approach. Everyone with fast streams has a stack where if all the modules arent real streams but run in "cheat" mode as it were use different code paths. Alan