Re: STREAMS: interface versus implementation

Alan Cox (alan@lxorguk.ukuu.org.uk)
Wed, 16 Sep 1998 01:28:10 +0100 (BST)

> >Please keep getpmsg/putmsg out of the generic glibc. Thats important because
> >otherwise glibc will break the syscall versions and calderas stuff
>
> Uh oh. This only came up because the LiS people approached Ulrich about
> doing exactly that (well sort of). He referred them to me since I'd been
> looking at TLI.

Nod

> glibc 2.1 has stubs for getpmsg/putpmsg (-ENOSYS always) and they have
> reserved syscall numbers in the devel kernel, so I thought there wouldn't be
> a problem with it. Can you explain what you're worried about, so I can give
> them a concrete reason to bug off?

Firstly:
glibc 2.1.x ought to issue the getpmsg putmsg syscalls and see if they return
-ENOSYS. Those syscalls are in 2.0.36pre9+ too (as -ENOSYS hooks)

Second:

If you emulate streams in user space and do so by nicking getpmsg. The kernel
syscall edition of getpmsg used by streams stuff using the Gcom code wont
work. You almost want two versions of libtli

-
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/