From: z...@rabi.columbia.edu (Zack Weinberg)
Subject: STREAMS: interface versus implementation
Date: 1998/09/15
Message-ID: <199809151321.JAA23674@rabi.phys.columbia.edu>#1/1
X-Deja-AN: 391488734
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
Newsgroups: muc.lists.linux-kernel
I've been talking to some of the LiS people regarding updating their
code to work with 2.1. In the course of this conversation a question
came up.
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. Pushable modules can be faked: for example, pushing the
tty module could either do nothing or fail depending on whether the fd
in question is already a tty. If done right this thin layer should
impose no performance penalty on code that doesn't use it, and should
not interfere with future improvements in the kernel.
Or so I would think. I'm not a kernel person. Is there something
obvious I've missed?
zw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: a...@lxorguk.ukuu.org.uk (Alan Cox)
Subject: Re: STREAMS: interface versus implementation
Date: 1998/09/15
Message-ID: <m0zJ3rb-000aQwC@the-village.bc.nu>#1/1
X-Deja-AN: 391523673
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <199809151321.JAA23674@rabi.phys.columbia.edu>
Newsgroups: muc.lists.linux-kernel
> 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?
What you put in user space doesnt really matter. Its completely outside
the kernel and it has no impact on performance of other code or maintenance
impact (except yours)
> implement these as a thin layer on top of the existing network and
> terminal code. Pushable modules can be faked: for example, pushing the
> tty module could either do nothing or fail depending on whether the fd
iBCS2 already does most of this sort of game in its SCO emulation in
kernel space - using these sort of techniques.
> in question is already a tty. If done right this thin layer should
> impose no performance penalty on code that doesn't use it, and should
> not interfere with future improvements in the kernel.
I question if you need it. The only non-protocol stack use of streams tends
to be TLI. Alexey Kuznetsov has a user space TLI emulation layer for linux
if someone wants to beat it back into shape
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: z...@rabi.columbia.edu (Zack Weinberg)
Subject: Re: STREAMS: interface versus implementation
Date: 1998/09/15
Message-ID: <199809151647.MAA26154@rabi.phys.columbia.edu>#1/1
X-Deja-AN: 391494613
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <199809151615.JAA22021@bitmover.com>
Newsgroups: muc.lists.linux-kernel
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 majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: a...@lxorguk.ukuu.org.uk (Alan Cox)
Subject: Re: STREAMS: interface versus implementation
Date: 1998/09/15
Message-ID: <m0zJ3wC-000aQwC@the-village.bc.nu>#1/1
X-Deja-AN: 391528526
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <199809151647.MAA26154@rabi.phys.columbia.edu>
Newsgroups: muc.lists.linux-kernel
> That means implementing getpmsg() and putpmsg() which are recv() and send()
> only different. It also means faking the STREAMS ioctls and /dev entries:
Please keep getpmsg/putmsg out of the generic glibc. Thats important because
otherwise glibc will break the syscall versions and calderas stuff
> Some help from the kernel is necessary, because putting a wrapper around
> ioctl in libc would kill performance for everyone.
LD_PRELOAD is your friend
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: z...@rabi.columbia.edu (Zack Weinberg)
Subject: Re: STREAMS: interface versus implementation
Date: 1998/09/15
Message-ID: <199809152315.TAA01141@rabi.phys.columbia.edu>#1/1
X-Deja-AN: 391543662
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <m0zJ3wC-000aQwC@the-village.bc.nu>
Newsgroups: muc.lists.linux-kernel
On Tue, 15 Sep 1998 23:51:07 +0100 (BST), Alan Cox wrote:
>> That means implementing getpmsg() and putpmsg() which are recv() and send()
>> only different. It also means faking the STREAMS ioctls and /dev entries:
>
>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.
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?
zw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: a...@lxorguk.ukuu.org.uk (Alan Cox)
Subject: Re: STREAMS: interface versus implementation
Date: 1998/09/16
Message-ID: <m0zJ5S6-000aQwC@the-village.bc.nu>#1/1
X-Deja-AN: 391543661
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <199809152315.TAA01141@rabi.phys.columbia.edu>
Newsgroups: muc.lists.linux-kernel
> >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 majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: drep...@cygnus.com (Ulrich Drepper)
Subject: Re: STREAMS: interface versus implementation
Date: 1998/09/16
Message-ID: <r2vhmpq63d.fsf@happy.cygnus.com>#1/1
X-Deja-AN: 391553061
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <m0zJ3wC-000aQwC@the-village.bc.nu>
Reply-To: drep...@cygnus.com (Ulrich Drepper)
Newsgroups: muc.lists.linux-kernel
a...@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.
> LD_PRELOAD is your friend
Again, no. LD_PRELOAD should not be used for anything unless
absolutely necessary. And for this situation I don't understand where
you want to use it. If a program is written with STREAMS in mind you
cannot compile it some way and then magically add the STREAMS library
at runtime.
--
---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com `------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: a...@lxorguk.ukuu.org.uk (Alan Cox)
Subject: Re: STREAMS: interface versus implementation
Date: 1998/09/16
Message-ID: <m0zJ66f-000aQwC@the-village.bc.nu>#1/1
X-Deja-AN: 391553060
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <r2vhmpq63d.fsf@happy.cygnus.com>
Newsgroups: muc.lists.linux-kernel
>
> a...@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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: z...@rabi.columbia.edu (Zack Weinberg)
Subject: Re: STREAMS: interface versus implementation
Date: 1998/09/16
Message-ID: <199809160015.UAA01754@rabi.phys.columbia.edu>#1/1
X-Deja-AN: 391553062
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <m0zJ66f-000aQwC@the-village.bc.nu>
Newsgroups: muc.lists.linux-kernel
On Wed, 16 Sep 1998 02:10:05 +0100 (BST), Alan Cox wrote:
>>
>> a...@lxorguk.ukuu.org.uk (Alan Cox) writes:
>>
>> > Please keep getpmsg/putmsg out of the generic glibc. Thats important becau
>se
>> > 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.
zw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: z...@rabi.columbia.edu (Zack Weinberg)
Subject: Re: STREAMS: interface versus implementation
Date: 1998/09/16
Message-ID: <199809160026.UAA01880@rabi.phys.columbia.edu>#1/1
X-Deja-AN: 391548523
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <m0zJ66f-000aQwC@the-village.bc.nu>
Newsgroups: muc.lists.linux-kernel
I said:
>
>On Wed, 16 Sep 1998 02:10:05 +0100 (BST), Alan Cox wrote:
>>>
>>> a...@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 majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: a...@lxorguk.ukuu.org.uk (Alan Cox)
Subject: Re: STREAMS: interface versus implementation
Date: 1998/09/16
Message-ID: <m0zJ6wm-000aQwC@the-village.bc.nu>#1/1
X-Deja-AN: 391562385
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <199809160026.UAA01880@rabi.phys.columbia.edu>
Newsgroups: muc.lists.linux-kernel
> The functions that look like they need some kernel help are:
>
> getpmsg putpmsg isastream fattach fdetach (latter three map to ioctls)
Fine, so put them in the library
> open("/dev/foo") for foo = tcp, udp, maybe arp, icmp, ip, eth
Thats a user space problem. You can intercept open() for this
> 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.)
Just overload the ioctl symbol
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: acaha...@cs.uml.edu (Albert D. Cahalan)
Subject: Re: STREAMS: interface versus implementation
Date: 1998/09/16
Message-ID: <199809160548.BAA09953@jupiter.cs.uml.edu>#1/1
X-Deja-AN: 391615306
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
Newsgroups: muc.lists.linux-kernel
Alan Cox writes:
>> The functions that look like they need some kernel help are:
>>
>> getpmsg putpmsg isastream fattach fdetach (latter three map to ioctls)
>
> Fine, so put them in the library
>
>> open("/dev/foo") for foo = tcp, udp, maybe arp, icmp, ip, eth
>
> Thats a user space problem. You can intercept open() for this
>
>> 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.)
>
> Just overload the ioctl symbol
That stinks. While nobody expects STREAMS to be really fast,
they shouldn't add severe overhead to libc. That includes the
non-STREAMS part of an application that uses STREAMS.
Your suggestions have a time cost in userspace. The kernel already
handles devices and ioctls, so a few more is no overhead.
He didn't suggest a rewrite of the TCP/IP stack, so relax.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: a...@lxorguk.ukuu.org.uk (Alan Cox)
Subject: Re: STREAMS: interface versus implementation
Date: 1998/09/16
Message-ID: <m0zJIyA-000aQwC@the-village.bc.nu>#1/1
X-Deja-AN: 391715260
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <199809160548.BAA09953@jupiter.cs.uml.edu>
Newsgroups: muc.lists.linux-kernel
> > Just overload the ioctl symbol
>
> That stinks. While nobody expects STREAMS to be really fast,
> they shouldn't add severe overhead to libc. That includes the
> non-STREAMS part of an application that uses STREAMS.
Tragedy.
1. Anyone who needed that performance wouldnt be using streams they'd
be rewriting.
2. It only affects anything linked with said streams library.
3. The "severe overhead argument" is complete shit. You are
adding
if(*(u32 *)pathname='/dev')
to most opens. 2 clocks at most with branch prediction in
your favour and about 5 or 6 additional long sized comparisons
for the slow path.
That will be lost in the noise after you've opened your first
emulated stream.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: acaha...@cs.uml.edu (Albert D. Cahalan)
Subject: Re: STREAMS: interface versus implementation
Date: 1998/09/16
Message-ID: <199809161810.OAA27650@jupiter.cs.uml.edu>#1/1
X-Deja-AN: 391859784
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <m0zJIyA-000aQwC@the-village.bc.nu>
Newsgroups: muc.lists.linux-kernel
>>> Just overload the ioctl symbol
>>
>> That stinks. While nobody expects STREAMS to be really fast,
>> they shouldn't add severe overhead to libc. That includes the
>> non-STREAMS part of an application that uses STREAMS.
>
> Tragedy.
>
> 1. Anyone who needed that performance wouldnt be using streams they'd
> be rewriting.
That's surely a great way to encourage Linux ports. Let's tell
all the app vendors that they must rewrite to get tolerable
performance on Linux.
> 2. It only affects anything linked with said streams library.
Yes, but it affects the whole application including normal file access.
If the overhead was really so low then we'd just change the normal
open() wrapper in libc.
> 3. The "severe overhead argument" is complete shit. You are
> adding
>
> if(*(u32 *)pathname='/dev')
>
> to most opens. 2 clocks at most with branch prediction in
I see an alignment trap too, but anyway...
The kernel version is free. We already have to handle device
operations and ioctls in the kernel. Libc would need an extra check,
while the kernel would not.
Lots of things don't _need_ to be in the kernel. We could get rid
of getcwd() and sendfile() without trouble, but we have them for
performance reasons. The device file and ioctls that were requested
would help STREAMS apps without messing up the network stack.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: ty...@MIT.EDU (Theodore Y. Ts'o)
Subject: Re: STREAMS: interface versus implementation
Date: 1998/09/16
Message-ID: <199809162239.SAA05667@dcl.MIT.EDU>#1/1
X-Deja-AN: 391907003
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <199809161810.OAA27650@jupiter.cs.uml.edu>
Newsgroups: muc.lists.linux-kernel
From: "Albert D. Cahalan" <acaha...@cs.uml.edu>
Date: Wed, 16 Sep 1998 14:10:22 -0400 (EDT)
That's surely a great way to encourage Linux ports. Let's tell
all the app vendors that they must rewrite to get tolerable
performance on Linux.
Just asking....
Does anyone know of any significant base of application code that really
does use Streams instead of a BSD Sockets-type interface? In my
experience, the vast majority of the network applications use BSD
Sockets, followed by a smaller number of programs which use TLI (TLI is
layered on top of Streams), and only a very, very, few applications
actually use the raw streams calls.
And for the ones that do, most of them are doing something non-standard
things that you couldn't do through TLI anyway, such as push a
non-standard telephony-based module on the Stream, which wouldn't be
supported without rewriting the kernel networking stack to use STREAMS
all the way through, and suffering the resulting performance penalties.
So for many of these apps, our adding the Streams user-mode support in
the kernel won't actually buy us anything.
So before we whip ourselfs into a lather about this subject, can we
please do a reality check and see if it really matters? As I said in an
earlier post (which was ignored, as far as I can tell), it would be
helpful for someone to identify a one or more applications which will
actually benefit from this work before starting this project.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: acaha...@cs.uml.edu (Albert D. Cahalan)
Subject: Re: STREAMS: interface versus implementation
Date: 1998/09/17
Message-ID: <199809170347.XAA18469@jupiter.cs.uml.edu>#1/1
X-Deja-AN: 391947276
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
Newsgroups: muc.lists.linux-kernel
Theodore Y. Ts'o writes:
> Does anyone know of any significant base of application code that
> really does use Streams instead of a BSD Sockets-type interface?
AFAIK it is used by boring business software. It's the stuff people
might need, not the stuff people have fun with. Software that runs
on gross systems like SCO OpenServer could be ported to Linux.
(so don't expect to find free source code)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: l...@bitmover.com (Larry McVoy)
Subject: Re: STREAMS: interface versus implementation
Date: 1998/09/17
Message-ID: <199809170608.XAA27181@bitmover.com>#1/1
X-Deja-AN: 391963609
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
Newsgroups: muc.lists.linux-kernel
: Theodore Y. Ts'o writes:
: > Does anyone know of any significant base of application code that
: > really does use Streams instead of a BSD Sockets-type interface?
:
"Albert D. Cahalan" <acaha...@cs.uml.edu>
: AFAIK it is used by boring business software. It's the stuff people
: might need, not the stuff people have fun with. Software that runs
: on gross systems like SCO OpenServer could be ported to Linux.
This doesn't answer the question. Please list by name the software
applications (not counting drivers) which use STREAMS. Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: acaha...@cs.uml.edu (Albert D. Cahalan)
Subject: Re: STREAMS: interface versus implementation
Date: 1998/09/17
Message-ID: <199809171232.IAA07976@jupiter.cs.uml.edu>#1/1
X-Deja-AN: 392037875
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
Newsgroups: muc.lists.linux-kernel
Larry McVoy writes:
>> Theodore Y. Ts'o writes:
>
>>> Does anyone know of any significant base of application code that
>>> really does use Streams instead of a BSD Sockets-type interface?
>
> "Albert D. Cahalan" <acaha...@cs.uml.edu>
>> AFAIK it is used by boring business software. It's the stuff people
>> might need, not the stuff people have fun with. Software that runs
>> on gross systems like SCO OpenServer could be ported to Linux.
>
> This doesn't answer the question. Please list by name the software
> applications (not counting drivers) which use STREAMS. Thanks.
You trimmed "(so don't expect to find free source code)", which was
rather important. I have heard Sybase requires STREAMS though.
Gee, maybe that's why Sybase still hasn't been ported to Linux.
Every other database vendor did, except Microsoft and (maybe) IBM.
Anyway, it's not as if someone wants a STREAMS TCP/IP stack. Relax.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: m...@paktronix.com (Matthew G. Marsh)
Subject: Re: STREAMS: interface versus implementation
Date: 1998/09/17
Message-ID: <Pine.LNX.4.00.9809170640110.15788-100000@pakrat.pakuni.net>#1/1
X-Deja-AN: 392048066
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <199809170608.XAA27181@bitmover.com>
Newsgroups: muc.lists.linux-kernel
On Wed, 16 Sep 1998, Larry McVoy wrote:
> : Theodore Y. Ts'o writes:
> : > Does anyone know of any significant base of application code that
> : > really does use Streams instead of a BSD Sockets-type interface?
> :
>
> "Albert D. Cahalan" <acaha...@cs.uml.edu>
> : AFAIK it is used by boring business software. It's the stuff people
> : might need, not the stuff people have fun with. Software that runs
> : on gross systems like SCO OpenServer could be ported to Linux.
>
> This doesn't answer the question. Please list by name the software
> applications (not counting drivers) which use STREAMS. Thanks.
OK. I have been following this wondering if anyone remembers the thread
earlier in the spring/summer about the port of Novell Netware to Linux by
Caldera. Netware uses streams and unfortunately one of the engineers from
Caldera snitted about streams support in the kernel. Twas a bad spree.
A user/module based STREAMS would be just the ticket for supporting
Netware under Linux. Much better than the current patch the kernel for
streams method. As I end up doing much work integrating Netware and Linux
(Netware 5.0 is awesome in combination with Linux management!!) it would
be nice to be able to use Caldera's Netware for Linux on the new kernels.
Anyway - 1. Novell Portable Netware 4.10b uses STREAMS.
--------------------------------------------------
Matthew G. Marsh, President
Paktronix Systems, LLC
1506 North 59th Street
Omaha NE 68104
Phone: (402) 932-7250
Email: m...@paktronix.com
WWW: http://www.paktronix.com
--------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: z...@rabi.columbia.edu (Zack Weinberg)
Subject: Re: STREAMS: interface versus implementation
Date: 1998/09/17
Message-ID: <199809171455.KAA11583@rabi.phys.columbia.edu>#1/1
X-Deja-AN: 392119678
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
Newsgroups: muc.lists.linux-kernel
On Wed, 16 Sep 1998 23:08:58 -0600, Larry McVoy <l...@bitmover.com> wrote:
> : Theodore Y. Ts'o writes:
> : > Does anyone know of any significant base of application code that
> : > really does use Streams instead of a BSD Sockets-type interface?
>
> "Albert D. Cahalan" <acaha...@cs.uml.edu>
> : AFAIK it is used by boring business software. It's the stuff people
> : might need, not the stuff people have fun with. Software that runs
> : on gross systems like SCO OpenServer could be ported to Linux.
>
> This doesn't answer the question. Please list by name the software
> applications (not counting drivers) which use STREAMS. Thanks.
I've asked the LiS people to go find such a list. If and when they find
one, we'll work on a user-space emulation library and/or a kernel module.
Until then I'll concentrate on getting ANK's TLI-over-sockets into libc.
zw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: ty...@MIT.EDU (Theodore Y. Ts'o)
Subject: Re: STREAMS: interface versus implementation
Date: 1998/09/17
Message-ID: <199809171636.MAA07607@dcl.MIT.EDU>#1/1
X-Deja-AN: 392168483
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <Pine.LNX.4.00.9809170640110.15788-100000@pakrat.pakuni.net>
Newsgroups: muc.lists.linux-kernel
Date: Thu, 17 Sep 1998 06:45:14 -0500 (CDT)
From: "Matthew G. Marsh" <m...@paktronix.com>
OK. I have been following this wondering if anyone remembers the thread
earlier in the spring/summer about the port of Novell Netware to Linux by
Caldera. Netware uses streams and unfortunately one of the engineers from
Caldera snitted about streams support in the kernel. Twas a bad spree.
Again, though --- was that the low-level STREAMS interface, or the
higher-level TLI interface?
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: nix-ker...@esperi.demon.co.uk (Nix)
Subject: Re: STREAMS: interface versus implementation
Date: 1998/09/17
Message-ID: <13825.33766.986548.214518@loki.wkstn.nix>#1/1
X-Deja-AN: 392279311
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <m0zJ5S6-000aQwC@the-village.bc.nu>
Newsgroups: muc.lists.linux-kernel
Alan Cox writes:
> the getpmsg putmsg syscalls
> Those syscalls are in 2.0.36pre9+ too (as -ENOSYS hooks)
This is confusing.
Why add additional unimplemented syscalls to a hopefully-near-
the-end-of-its-life stable kernel branch? I'd agree that it is
unlikely to affect anything - except, for instance, for binary modules
that add syscalls with the same numbers, &c, &c...
... I think that perhaps `if there is any reason not to add it don't
add it' should apply here; is my guessed reason above complete
garbage? (Probably it is.)
--
`This is as interesting as watching paint dry.' - K.
`You could do the washing up in the meantime.' - Y.
*pause while badblocks(8) churns onwards*
`Let's watch some more paint.' - K.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: a...@lxorguk.ukuu.org.uk (Alan Cox)
Subject: Re: STREAMS: interface versus implementation
Date: 1998/09/17
Message-ID: <m0zJn0A-000aQwC@the-village.bc.nu>#1/1
X-Deja-AN: 392270251
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <13825.33766.986548.214518@loki.wkstn.nix>
Newsgroups: muc.lists.linux-kernel
> Why add additional unimplemented syscalls to a hopefully-near-
> the-end-of-its-life stable kernel branch? I'd agree that it is
Because it makes it easier for caldera to maintain their module
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: m...@paktronix.com (Matthew G. Marsh)
Subject: Re: STREAMS: interface versus implementation
Date: 1998/09/18
Message-ID: <Pine.LNX.4.00.9809171903190.17216-100000@pakrat.pakuni.net>#1/1
X-Deja-AN: 392313168
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <199809171636.MAA07607@dcl.MIT.EDU>
Newsgroups: muc.lists.linux-kernel
On Thu, 17 Sep 1998, Theodore Y. Ts'o wrote:
> Date: Thu, 17 Sep 1998 06:45:14 -0500 (CDT)
> From: "Matthew G. Marsh" <m...@paktronix.com>
>
> OK. I have been following this wondering if anyone remembers the thread
> earlier in the spring/summer about the port of Novell Netware to Linux by
> Caldera. Netware uses streams and unfortunately one of the engineers from
> Caldera snitted about streams support in the kernel. Twas a bad spree.
>
> Again, though --- was that the low-level STREAMS interface, or the
> higher-level TLI interface?
It was the entire LiS implementation. I just looked through the patch and
it seems the putpmsg, getpmsg, poll syscalls are defined along with a
whole pile of assembly code. I do not know the extant of the patching only
that it was written specifically for 2.0.34 (and later 2.0.35). If I had
to guess bearing on the way Netware works I would say they implemented
both low-level STREAMS and TLI.
>
> - Ted
>
--------------------------------------------------
Matthew G. Marsh, President
Paktronix Systems, LLC
1506 North 59th Street
Omaha NE 68104
Phone: (402) 932-7250
Email: m...@paktronix.com
WWW: http://www.paktronix.com
--------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: ty...@MIT.EDU (Theodore Y. Ts'o)
Subject: Re: STREAMS: interface versus implementation
Date: 1998/09/18
Message-ID: <199809180230.WAA07836@dcl.MIT.EDU>#1/1
X-Deja-AN: 392317305
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <Pine.LNX.4.00.9809171903190.17216-100000@pakrat.pakuni.net>
Newsgroups: muc.lists.linux-kernel
Date: Thu, 17 Sep 1998 19:06:55 -0500 (CDT)
From: "Matthew G. Marsh" <m...@paktronix.com>
It was the entire LiS implementation. I just looked through the patch and
it seems the putpmsg, getpmsg, poll syscalls are defined along with a
whole pile of assembly code. I do not know the extant of the patching only
that it was written specifically for 2.0.34 (and later 2.0.35). If I had
to guess bearing on the way Netware works I would say they implemented
both low-level STREAMS and TLI.
If I'm not mistaken, the whole LiS implementation requires kernel
patches, and installation of the STREAMS networking layer in the kernel.
That's already been ruled out of court due to the performance impacts of
STREAMS model. (See the kernel FAQ, or ask Davem how badly Linux
trounces the Solaris networking layer these days. :-)
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
From: jf...@sovereign.org (Jim Freeman)
Subject: Re: STREAMS: interface versus implementation
Date: 1998/09/18
Message-ID: <199809181347.HAA00847@sovereign.sovereign.org>#1/1
X-Deja-AN: 392417525
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <199809180230.WAA07836@dcl.MIT.EDU>
Newsgroups: muc.lists.linux-kernel
Ted writes:
> If I'm not mistaken, the whole LiS implementation requires kernel
> patches, and installation of the STREAMS networking layer in the kernel.
> That's already been ruled out of court due to the performance impacts of
> STREAMS model. (See the kernel FAQ, or ask Davem how badly Linux
> trounces the Solaris networking layer these days. :-)
The patches are minimal (a few lines) and back-port 2.1 functionality
into 2.0. LiS then builds as a loadable module, exporting
STREAMS DDI entry points. 2.0.36 may include the necessary patches
(dunno - haven't looked, but I understand it at least includes the
{get,put}pmsg syscall entries).
STREAMS supplanting Linux's native networking is not the point.
Exploiting extant code bases is. GCOM (who maintains LiS these
days) have legacy (slow) connectivity h/w that has a substantial
code base in STREAMS - FR, X.25, SNA, ... - all low bandwidth stuff
that doesn't need the SCREAMING PERFORMANCE of Linux networking.
There are likewise big chunks of telephony STREAMS code out there
that can live and perform acceptably well in LiS. NetWare for Linux
(with its big chunks of STREAMS code) is targeted at small business
- mega-performance is not required.
For such STREAMS code bases, having Linux accomodate (but not include)
LiS lets vendors "try the Linux waters" without having to re-tool.
(Granted, they should just have a clue and be able to figure out all
by themselves that Linux is for real, but hey ... they're vendors).
Once they find success in the Linux market, there will be an obvious
incentive to release subsequent products written to native Linux
networking. Any of them sufficiently ignorant of Linux politics
and sensibilities to subsequently release "serious" (ie; ostensibly
performant) product based on STREAMS would then be publicly pilloried,
flailed, derided, scorned, etc. into Linux oblivion (a la the LSA).
If any of this is a re-hash of an earlier (dramatic?) STREAMS thread
on this list (I'm sorry to have missed it), I well and truly apologize
for wasting your bandwidth.
...jfree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
|