Messages in this thread |  | | From | Mark.Hemment@uniplex ... | Date | Thu, 20 Jun 96 15:57:51 +0100 | Subject | Re: 2.2.0 wishlist |
| |
Alan wrote:
>> No. STREAMS much more powerful than current interface is.
> Also much too slow.
>> You can emulate BSD socket interface (and ttys, and....) on the top of >> STREAMS (f.e. Solaris-2.*), but the reversed task is impossible. >> Only poor emulation, that is useless.
> You can emulate the whole of the user view of streams in user space, > properly and accurately with only a few small kernel hooks for the > operations sockets don't represent. And note that almost all of those > like > querying the next pending connection before accepting it are covered > in the Posix draft socket api
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 can help in multi-threading a kernel (multiple-thread the STREAMS correctly, and the drivers/modules follow - well, almost, yes?). 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. Being able to pass pipes between unrealted processes....
I first met kernel STREAMS a few years back (writing STREAMS drivers/ modules for an ISDN protocol stack). Yes, the concept does have a few faults, and nasty kludges in some places to make them usable as sockets. I cannot agree they are 'too slow'.
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?
markhe
|  |