Re: STREAMS: interface versus implementation

Zack Weinberg (zack@rabi.columbia.edu)
Tue, 15 Sep 1998 12:47:15 -0400


On Tue, 15 Sep 1998 09:15:38 -0600, Larry McVoy wrote:
>: STREAMS has been kept out of the kernel because the internal structure
>: and device-driver interface are slow and bloated. Would there be the
>: same opposition to including the user-space interface?
>:
>: By user-space interface I mean getpmsg, putpmsg, the streams ioctls,
>: and some /dev entries. It seems to me that it would be possible to
>: implement these as a thin layer on top of the existing network and
>: terminal code.
>
>STREAMS includes DLPI - a driver/kernel interface for networking drivers.
>In fact, I think that is the most often used feature of STREAMS. The kernel
>is never going to accept STREAMS drivers.

That's fine with me.

>What you are talking about is making STREAMS modules possible.

Actually no. I'm a libc hacker. All I care about is being able to take a
_user_ program written to STREAMS and port it to Linux with a recompile.

That means implementing getpmsg() and putpmsg() which are recv() and send()
only different. It also means faking the STREAMS ioctls and /dev entries:

open("/dev/tcp", O_RDWR) = socket(PF_INET, SOCK_STREAM)

ioctl(fd, I_STR, { TI_BIND, address }) = bind(fd, address)

and so forth.

If ioctl(fd, I_PUSH, "blah") doesn't do anything, I doubt anyone will
notice.

Some help from the kernel is necessary, because putting a wrapper around
ioctl in libc would kill performance for everyone.

zw

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/