This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Tue Oct 3 09:08:07 2023 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 QAA13781 for ; Thu, 20 Jun 1996 16:10:47 -0500 Received: from vger.rutgers.edu by orchard.washtenaw.cc.mi.us (8.6.10/2.3) with ESMTP id QAA18376; Thu, 20 Jun 1996 16:58:55 -0400 Received: by vger.rutgers.edu id <106094-7187>; Thu, 20 Jun 1996 16:42:35 -0500 From: Mark.Hemment@uniplex.co.uk X-OpenMail-Hops: 1 Date: Thu, 20 Jun 96 18:20:17 +0100 Message-Id: In-Reply-To: <199606201553.QAA13202@snowcrash.cymru.net> Subject: Re: 2.2.0 wishlist To: alan@cymru.net Cc: Mark.Hemment@uniplex.co.uk, inr-linux-kernel@ms2.inr.ac.ru, linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk Alan Wrote: >> That can be used to pass data directly between a device's dual-ported >> memory up into user's process. > No Opps. Maybe not into user-space! But they do allow such memory to be passed all the way to the stream-head. OK, you can do similar (better?) with other methods, but I found using a release pointer for a data block flexible. > 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" There is no way I can disagree, or would want to disagree, with names like that. I've learnt something. >> 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) Would that be M$'s Visual Basic? :) I found STREAMS a v. good service for what we were trying to do. If we were trying to pump data down an FDDI at 100Mbips, maybe we would have found the implementation/design lacking - I don't know. STREAMS allowed us to concentrate more on the ISDN protocol, rather than worrying about a lot of other details. We also got some good debug support from the service (a God send!). Not every line of code in the kernel needs to be optimised down to the last cycle (although in an idea world, it would), __sometimes__ a working implementation is better than no implementation (this last line sounds like flame bait, please note the underlining of 'sometimes'). > 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. I though STREAMS managed to avoid a lot of memory copies, and uses caches of common objects/data sizes to speed up allocation. It is also possible to pass a message 'over' a 'layer'. Maybe I've misunderstood your point... Regards, markhe