Re: STREAMS: interface versus implementation

Zack Weinberg (zack@rabi.columbia.edu)
Tue, 15 Sep 1998 20:26:18 -0400


I said:
>
>On Wed, 16 Sep 1998 02:10:05 +0100 (BST), Alan Cox wrote:
>>>
>>> alan@lxorguk.ukuu.org.uk (Alan Cox) writes:
>>>
>>>> Please keep getpmsg/putmsg out of the generic glibc. Thats
>>>> important because otherwise glibc will break the syscall versions
>>>> and calderas stuff
>>>
>>> No. The symbols coming from glibc would be shadowed by the
>>> symbols in other libraries.
>>
>> Exactly
>>
>> getmsg and putmsg now are syscalls. Zach proposes user space
>> emulation. If the glibc uses the user space stuff it wont be able
>> to make the syscall version
>
> Actually I was proposing kernel space emulation a la iBCS.

I should clarify perhaps. I was proposing kernel space emulation of
the streams primitives, via a loadable module. They'd either map to
existing socket or terminal primitives, or be no-ops. (The LiS people
have volunteered to write this.)

I may have confused you by saying that glibc would implement TLI over
sockets. That's entirely separate.

The functions that look like they need some kernel help are:

getpmsg putpmsg isastream fattach fdetach (latter three map to ioctls)

open("/dev/foo") for foo = tcp, udp, maybe arp, icmp, ip, eth

ioctl(fd, I_xyz, data) for various I_xyz ioctls. (Many of these just
need to do nothing and return 0 instead of failing with -ENOSYS.)

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/