From: Keith Nichol <kei...@ind.tansu.com.au>
Subject: STREAMS?
Date: 1998/07/30
Message-ID: <35C01137.592AF279@ind.tansu.com.au>#1/1
X-Deja-AN: 376250056
Content-Transfer-Encoding: 7bit
Organization: Telstra Corporation
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0
Newsgroups: comp.os.linux.development.system
I know about Gcom's LiS.
QUESTIONS: Are the kernel patches integrated into any "production"
kernel yet, be it stable or development? If not, does anyone have any
idea if or when they will be?
Cheers
Keith
--
Keith Nichol | Address : Level 2, 175 Liverpool St,
Telstra Intelligent Network Platforms | Sydney 2000, Australia
| Phone : (+61) 2 9206 3429
mailto:kei...@ind.tansu.com.au | Fax : (+61) 2 9281 1301
From: Nix <{$er...@esperi.demon.co.uk>
Subject: Re: STREAMS?
Date: 1998/07/31
Message-ID: <87soji25nd.fsf@loki.wkstn.nix>#1/1
X-Deja-AN: 376524535
X-NNTP-Posting-Host: esperi.demon.co.uk:194.222.138.8
References: <35C01137.592AF279@ind.tansu.com.au>
X-Complaints-To: abuse@demon.net
X-Trace: news.demon.co.uk 901847467 nnrp-06:3975
NO-IDENT esperi.demon.co.uk:194.222.138.8
Organization: the Core
Newsgroups: comp.os.linux.development.system
Keith Nichol <kei...@ind.tansu.com.au> writes:
> I know about Gcom's LiS.
>
> QUESTIONS: Are the kernel patches integrated into any "production"
> kernel yet, be it stable or development? If not, does anyone have any
> idea if or when they will be?
Indications from linux-kernel are that they will not be released as part
of an official kernel, now or ever.
There is a fairly concrete consensus among the top developers that
STREAMS is simply Not Going In.
--
`It is inelegant and it was hacked on. But it was hacked on with
careful consideration.' - PLA on perl and OO
From: m_sch...@informatik.infomatik.uni-frankfurt.de (Michael Schneider)
Subject: Re: STREAMS?
Date: 1998/07/31
Message-ID: <6prd28$hal$4@zeus.rbi.informatik.uni-frankfurt.de>#1/1
X-Deja-AN: 376557606
References: <35C01137.592AF279@ind.tansu.com.au> <87soji25nd.fsf@loki.wkstn.nix>
Organization: Johann Wolfgang Goethe-Universitaet Frankfurt/Main
Reply-To: m_sch...@cs.uni-frankfurt.de
Newsgroups: comp.os.linux.development.system
Nix ({$er...@esperi.demon.co.uk) wrote:
> There is a fairly concrete consensus among the top developers that
> STREAMS is simply Not Going In.
However, some months ago I read an anouncement from someone,
who has an implementation of "SysV-streams for linux". Maybe
some modules?!
Michael
--
sending M$ Windows the KILL sig...
From: k...@kdl.sc.scruznet.com (Ken Latta)
Subject: Re: STREAMS?
Date: 1998/07/31
Message-ID: <6prfuj$d1g$1@supernews.com>#1/1
X-Deja-AN: 376557608
References: <35C01137.592AF279@ind.tansu.com.au> <87soji25nd.fsf@loki.wkstn.nix>
<6prd28$hal$4@zeus.rbi.informatik.uni-frankfurt.de>
To: m_sch...@cs.uni-frankfurt.de
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: newsabuse@supernews.com
X-Trace: 901858067 MPCBFHUBS652FA5E3C usenet53.supernews.com
Organization: http://www.supernews.com, The World's Usenet: Discussions Start Here
Mime-Version: 1.0
Newsgroups: comp.os.linux.development.system
[Posted and mailed]
In article <6prd28$ha...@zeus.rbi.informatik.uni-frankfurt.de>,
m_sch...@informatik.infomatik.uni-frankfurt.de (Michael Schneider) writes:
> Nix ({$er...@esperi.demon.co.uk) wrote:
>
>> There is a fairly concrete consensus among the top developers that
>> STREAMS is simply Not Going In.
>
> However, some months ago I read an anouncement from someone,
> who has an implementation of "SysV-streams for linux". Maybe
> some modules?!
>
>
> Michael
>
> --
> sending M$ Windows the KILL sig...
>
>
>
Caldera made an announcement today regarding Netware for Linux that
mentions they will soon be shipping a new CD with 2.0.35 kernel including
STREAMS.
--
Ken Latta
k...@kdl.sc.scruznet.com
From: Richard Blackstone <rblackst...@home.com>
Subject: Re: STREAMS?
Date: 1998/07/31
Message-ID: <Xsfw1.1091$se7.8970071@news.rdc1.ct.home.com>#1/1
X-Deja-AN: 376616374
References: <35C01137.592AF279@ind.tansu.com.au> <87soji25nd.fsf@loki.wkstn.nix>
<6prd28$hal$4@zeus.rbi.informatik.uni-frankfurt.de> <6prfuj$d1g$1@supernews.com>
Organization: Linux Powered
NNTP-Posting-Date: Fri, 31 Jul 1998 01:43:35 PDT
Newsgroups: comp.os.linux.development.system
Ken Latta <k...@kdl.sc.scruznet.com> wrote:
> [Posted and mailed]
> Caldera made an announcement today regarding Netware for Linux that
> mentions they will soon be shipping a new CD with 2.0.35 kernel including
> STREAMS.
> --
I have mixed feelings about this. Streams are SYSV 3.x and 4 features
that never made into POSIX. If the kernel developers don't express
official position on this, Linux is in danger of being balkanized
in the kernel level. The to-be-released glibc 2.1 (in beta now)
doesn't contain any library-level stream either, even though
the intention to implement one is clear. Until the kernel hackers
OK the added feature, let's hope the modification won't put
pressure on them.
The success of Linux relies on a stable and well-controlled kernel
development. Until now, the authority is well recognized as the
stable/development-kernel pair. If next time that Oracle and
Informix find it convenient to plug some unofficial patches into
their product and thus incompatible with the current Caldera kernel,
what are we going to do?
I strongly suggest that Linus stand firm in this regard. It is also
very important for other popular distributors to adhere to the only
standard kernel we have in order for end users to follow. The current
transition from libc5 to glibc has been a major headache of the
Linux community; we really don't need another one to make it worse.
REB
From: Paul Russell <Paul.Russ...@RustCorp.com.au>
Subject: Re: STREAMS?
Date: 1998/07/31
Message-ID: <83yatak0dd.fsf@kevin.rustcorp.com.au>
X-Deja-AN: 376632329
Sender: ru...@kevin.rustcorp.com.au
References: <35C01137.592AF279@ind.tansu.com.au>
X-Trace: 31 Jul 1998 19:41:12 +0950, dialup-ad-14-68.camtech.net.au
Organization: Camtech Internet Customer
Newsgroups: comp.os.linux.development.system
Keith Nichol <kei...@ind.tansu.com.au> writes:
> I know about Gcom's LiS.
>
> QUESTIONS: Are the kernel patches integrated into any "production"
> kernel yet, be it stable or development? If not, does anyone have any
> idea if or when they will be?
Hi Keith.
This question comes up with fair regularity on linux-kernel. Last
time it came up, Alan Cox summarized as follows. Please note that
streams are regularly debated, and regularly quashed by the core Linux
developers. Don't open this one again.
================================================================
From: a...@lxorguk.ukuu.org.uk (Alan Cox)
Subject: Streams and Linux
To: chr...@caldera.com, caldera-us...@rim.caldera.com
Date: Mon, 29 Jun 1998 02:03:30 +0100 (BST)
Cc: linux-ker...@vger.rutgers.edu
X-Orcpt: rfc822;linux-ker...@vger.rutgers.edu
Sender: owner-linux-ker...@vger.rutgers.edu
Precedence: bulk
X-Loop: majord...@vger.rutgers.edu
Content-Type: text
X-UIDL: a869be70dc1bb84b2a289ab4dd828f6f
[Red Hat firmly off, Linux hacker hat firmly on]
> pennies worth. All of the following is my personal opinion, worth
> every penny you have paid for it. :-)
I can't be bothered to even discuss the more stupid poltical aspects
of all this. I'm just going to explain technical issues - nothing more
or less.
> "convert" Streams code to "Linux-specific" alternatives necessarily
> preclude this kind of "conversion" as an option. Given this
> premise, we have two alternatives:
The are several things people muddle up
1. Streams
This is an API design for layered networking. Even the inventor
of the streams concept said of the way it was used
"The idea loses something when it is shouted"
Streams are technical very flawed and not a good thing to put in
a kernel. Indeed our Solaris, SunOS, SCO etc emulation layers
turn streams into sockets as fast as possible. (note btw ibcs2
does this -without- kernel patches), as could Caldera. Although
for the syscall registering issue there may be a sane reason for a
registering those. Ask Linus.
2. TLI/XTLI
These are the interfaces _most_ people actually use. TLI and XTLI
isolate the user from the innards of streams. TLI is actually
very flexible, it tends to be unpopular with non commercial people
because TLI programming is painful.
Alexey Kuznetsov wrote a complete TLI emulation over sockets layer
for Linux. Entirely in user space. Its free, it exists it addresses
most of the issues people often think are "streams". This TLI
implementation is free software.
So most TLI/XTLI applications are sorted. Finally almost all
applications in the commercial world are written to the socket API
(maybe emulated onto TLI). Thats another reason vendors are running
from streams as fast as they can.
> Besides, despite the strongly-held opinions of many persons, the
> jury is still out on whether or not "Streams performance" is all
> that bad. And even if the performance of Streams _is_ that bad,
The jury returned the final verdict about four years ago. There is no
argument about the technical flaws in streams: SGI do not use streams
internally for networking, Sun moved away from streams for the performance
parts of their networking (their papers imply what actually occurs is
"Hi Im a streams module but I do Sun funky network too" "Hi Im the other
module on this stack right now, I also do sun funky networking - lets
stuff this streams shit and talk sanely"). Sun moved socket() and friends
back into the kernel. Sequent moved sockets and socket API stuff back into
the kernel. Unixware Im reliably informed is currently doing the same.
So from a technical point of view streams is dead. There are people who
worked on streams for years at companies like Spider, who specialised
in making streams go as fast as is possible who will tell you it doesnt
go fast enough and equally importantly you cannot make it scale if you
want to be top of the pile.
Thats the technical status.
> isn't the most important issue. If I had a choice between _no
> application_ and a _slow application_ which met my critical needs,
> I'd choose the latter 100% of the time. Would you?
The Linux kernel is a technical project. Streams are "not interesting"
technically. Productization is a vendor issue.
> a mistake to tie "NetWare on Streams" with "NetWare performance".
> The two are entirely unrelated.
Indeed - netware is fast "despite streams" and "despite the netware
protocol weaknesses" - its a victory of sheer human stubbonness and hacking
skill over technically poor tools. You may care to benchmark netware 3
versus netware for unix on pure packet turn around time for a null NCP
operation. Now compare it with 2.1.x knfsd (socket based kernel code)
turning around an NFS no-op.
You will find it interesting.
> A: Because certain extensions to the kernel must be made in order to
> support the Streams loadable module. For example, Streams
> introduces some new system calls which are NOT present in the base
> kernel (e.g. putpmsg, getpmsg). The kernel system-call table must
> be modified to support these Streams entry points.
Syscall numbers you didnt register with Linus as far as I can tell, which
means since 2.2 uses more numbers you are likely to see breakages. Irrespective
of any streams issues those two calls as NULL hooks you could get dropped
into 2.1.x. Ask Linus - he did it for AFS. I cannot put anything like that
into 2.0 until it has official 2.1.x syscall numbers from the man himself
or I cause a back compatibility monster with a syscall numbering collision.
> that the kernel changes required to support a loadable Streams
> module are strikingly tiny. But there is such a "religious"
> opposition to Streams among _kernel developers_ that they refuse to
> allow even these tiny patches into the "base kernel". They seem to
It is entirely a technical opposition.
> fear the introduction of support for a Streams module as such a
> terrible "pollution" of their kernel that they have not and
> apparently will not allow it to happen. So Caldera is stuck--the
Putting support for something in the kernel implies a maintenance commitment
that in this case is not there. Ask Caldera or any vendor about the effect
of shipping a package you cant maintain. They can write in big letters
"this package is an add on its not supported", it makes no odds. So there
are real issues adding anything to a kernel - especially as its damned
hard to remove something from the kernel, even when its way more dumb than
say streams
That said I see no reason why Caldera shouldnt ask and get a pair of syscall
numbers from Linus they can hook.
> cases (e.g. NetWare for Linux), the software under consideration is
> proprietary and hence is not a candiate for a "freeware"
> reimplementation.
Actually there is MARS_NWE which is effectively exactly that. Caldera are
really selling a "branded" genuine netware. That I suspect makes the case
even more awkward for a rewrite. Again your cite is a political and
productization issue.
> A: I've been truly amazed at the "group opinion" on this subject.
If you were technically aware of whats going on in networking you wouldnt
be. Streams is being dropped globally. Streams was originally a victory
of standards people over sanity, its now being blasted into oblivion because
1. Networks have sped up by a factor of 100 in 3 years - Memory hasnt
2. Network performance is the hottest checklist item and its going to grow
faster and faster.
> Most people say that opposition to Streams is on technical grounds,
> but I believe the real opposition is a political one. Many people
I've never seen Linus with a political agenda. And even the people who get
political about streams (eg Larry McVoy) do so from a technical base point.
> be going out of their way to make Streams painful for everyone, as
> if to fulfill their own prophecies on the "badness" of Streams.
They don't need fulfilling.
> The fascinating thing going on here is the fear of the "success" of
> Linux: If someone wrote a "major application which depended on
It wouldnt be a success - it would be an app that screws the future of
the Linux networking stack. Right now we are the most shit hot piece of
PC networking software on the planet. The only people who can touch us
are FreeBSD (who also dont do streams).
Having an application that is streams dependant that makes it hard to break
the streams stuff isnt acceptable from a purely technical standpoint. Nor is
it good for the long term future of Linux.
What it means 3 years down the line is Linux would be bottom of the webstone
benchmark and all the nice "linux is fast" graphs that sell Linux webservers
will be gone, dead and history.
Linux is _technically superior_ - that is its fundamental superiority. The
core Linux product must continue to be so and the Linux core team agenda
is purely technical superiority
> the masses. (Not to mention David's unsupported assertion that the
> mere presence of Streams in the kernel cause the kernel itself to
> slow down--this just ain't so.)
It does. We cannot do zero copy page flipping in a streams environment. When
we do that the GCOM code _will_ probably break. I suspect it'll break in a
fixable way where it'll be even slower again but with 1Gigabit networking
once the cards support it , non zero copy networking is _not_ an option if
we want to stay top of the pile. So we will end up breaking the GCOM stuff
possibly pretty badly although I hope not, there is no malice in breaking
of things.
Another very worrying issue is field of interest in the support. Caldera
ship only x86 Linux. Has anyone ever even verified the GCOM streams code
is 64bit clean big and little endian, alignment clean, copes with ARM
packing rules and all the other little portability wonders the mainstream
code has to meet.
> I disagree with David's assertion that Streams will "creap" [sic]
> like a "fungus" into the rest of the kernel. Streams has a
> well-defined kernel interface that is not likely to change much
No streams does NOT have a well defined kernel interface. It has a poorly
defined set of interactions with core Linux data structures. You may not
be a good enough programmer to see that - I don't know your background. I've
worked on Linux since it appeared, I've worked for people like 3Com who
had this problem badly. Anything that has data structure interfaces with
other code leaks through the structures over the boundary, or ties down
those structures.
Streams depends on the sk_buffs in the kernel. In a zero copy world those
buffers may well just not exist any more
> it's maintained by some nice guys at Gcom, NOT the _kernel
> developers_. Linux Streams (LiS) has a lifetime of its own
For how long. Who maintains it if Caldera pull out of Linux to concentrate
on DOS only. Who maintains it if Caldera decide GCOM are charging too much.
Are Caldera committed to 2.2 support of it, have they discussed getting
the syscall numbers (which is all the actually need) from Linus ?
> A: This remains to be seen, but a couple come to mind. Firstly,
> Caldera's NetWare for Linux (NW4L) would definitely NOT be on Linux
> were it not for Streams. You can decide for yourself whether or
These are entirely non-technical issues, and you seem to be a bit short
of actual examples except the netware client, which has a free version
shipped in the standard kernels.
The decisions people like Linus and Davem make on what goes into the
kernel are purely technical ones. If Caldera think there is a market in
shipping a modified "streams aware" kernel good for them. Streams is a
marketing and productization issue not a technical issue. Streams ran out
of technical arguments a very long time ago. Right now every vendor is
trying to figure out how to get streams OUT of their box while keeping
legacy API compatibility code from bloating the kernel another 200 K.
We don't want to put that 200K in. Maybe to Caldera its a worthwhile
commercial product. As I've said - reserve your syscall numbers I cannot
see an opposition to that. Thats the advice I gave in 1996 or so when
this first came up.
Alan
================================================================
Rusty.
--
.sig lost in the mail
From: Nix <{$er...@esperi.demon.co.uk>
Subject: Re: STREAMS?
Date: 1998/08/01
Message-ID: <87sojgzqnz.fsf@loki.wkstn.nix>#1/1
X-Deja-AN: 376989557
X-NNTP-Posting-Host: esperi.demon.co.uk:194.222.138.8
References: <35C01137.592AF279@ind.tansu.com.au> <87soji25nd.fsf@loki.wkstn.nix>
<6prd28$hal$4@zeus.rbi.informatik.uni-frankfurt.de> <6prfuj$d1g$1@supernews.com>
<Xsfw1.1091$se7.8970071@news.rdc1.ct.home.com>
X-Complaints-To: abuse@demon.net
X-Trace: news.demon.co.uk 901987523 nnrp-10:4619
NO-IDENT esperi.demon.co.uk:194.222.138.8
Organization: the Core
Newsgroups: comp.os.linux.development.system
Richard Blackstone <rblackst...@home.com> writes:
> I have mixed feelings about this. Streams are SYSV 3.x and 4 features
> that never made into POSIX. If the kernel developers don't express
> official position on this, Linux is in danger of being balkanized
> in the kernel level.
According to Alan, Linus and several others, the official position
(as much as there ever is one) is `no'.
I don't think there is *one* regular linux-kernel contributor who
likes it (and certainly *this* lurker doesn't.)
> If next time that Oracle and
> Informix find it convenient to plug some unofficial patches into
> their product and thus incompatible with the current Caldera kernel,
> what are we going to do?
Oracle and Informix will find that they are restricting their market
unnecessarily and will fix it, I expect.
--
`It is inelegant and it was hacked on. But it was hacked on with
careful consideration.' - PLA on perl and OO
From: David Grothe <d...@gcom.com>
Subject: Re: STREAMS?
Date: 1998/08/03
Message-ID: <35C64666.AAF2E719@gcom.com>
X-Deja-AN: 377641389
Content-Transfer-Encoding: 7bit
References: <35C01137.592AF279@ind.tansu.com.au>
<83yatak0dd.fsf@kevin.rustcorp.com.au>
Content-Type: text/plain; charset=us-ascii
Organization: Gcom, Inc
MIME-Version: 1.0
Reply-To: d...@gcom.com
NNTP-Posting-Date: Mon, 03 Aug 1998 19:28:02 EDT
Newsgroups: comp.os.linux.development.system
(David Grothe is one of the co-authors of LiS STREAMS.)
Paul Russell wrote:
> Keith Nichol <kei...@ind.tansu.com.au> writes:
>
> > I know about Gcom's LiS.
> >
> > QUESTIONS: Are the kernel patches integrated into any "production"
> > kernel yet, be it stable or development? If not, does anyone have any
> > idea if or when they will be?
>
> Hi Keith.
>
> This question comes up with fair regularity on linux-kernel. Last
> time it came up, Alan Cox summarized as follows. Please note that
> streams are regularly debated, and regularly quashed by the core Linux
> developers. Don't open this one again.
>
> ================================================================
> From: a...@lxorguk.ukuu.org.uk (Alan Cox)
> Subject: Streams and Linux
> To: chr...@caldera.com, caldera-us...@rim.caldera.com
> Date: Mon, 29 Jun 1998 02:03:30 +0100 (BST)
>
> [Red Hat firmly off, Linux hacker hat firmly on]
>
> <snip>
>
> The are several things people muddle up
>
> 1. Streams
>
> This is an API design for layered networking. Even the inventor
> of the streams concept said of the way it was used
> "The idea loses something when it is shouted"
Correct, too much shouting.
>
>
> Streams are technical very flawed and not a good thing to put in
> a kernel. Indeed our Solaris, SunOS, SCO etc emulation layers
> turn streams into sockets as fast as possible. (note btw ibcs2
> does this -without- kernel patches), as could Caldera. Although
> for the syscall registering issue there may be a sane reason for a
> registering those. Ask Linus.
I have asked Linus twice to register the LiS system calls. No reply either time.
>
>
> <snip>
>
> > Besides, despite the strongly-held opinions of many persons, the
> > jury is still out on whether or not "Streams performance" is all
> > that bad. And even if the performance of Streams _is_ that bad,
>
> The jury returned the final verdict about four years ago. There is no
> argument about the technical flaws in streams: SGI do not use streams
> internally for networking, Sun moved away from streams for the performance
> parts of their networking (their papers imply what actually occurs is
> "Hi Im a streams module but I do Sun funky network too" "Hi Im the other
> module on this stack right now, I also do sun funky networking - lets
> stuff this streams shit and talk sanely").
SGI is a Berkeley based kernel and would not be expected to have STREAMs.
I talked to the people who provide Sun with TCP/IP for Solaris. Solaris is most
definitely STREAMS based. The "papers" to which you refer concern some special
mechanisms to map user space buffers into the kernel and save a data copy at the
user/kernel boundary. I am told that it has nothing to do with subverting STREAMS.
> Sun moved socket() and friends
> back into the kernel.
That is correct, but, again, it is still an interface library to STREAMS based
TCP/IP, not a path around STREAMS.
> Sequent moved sockets and socket API stuff back into
> the kernel.
I know nothing about Sequent, so can't comment.
> Unixware Im reliably informed is currently doing the same.
Apparently unreliable information. I have been working with UnixWare 7 for 6
months now. It is STREAMS based. SCO changed the interface below IP to add an
additional layer to make the MAC drivers dumber. So the MAC drivers no longer have
to speak DLPI, but a smaller vocabulary provided by this additional layer. It is
still STREAMS based all the way down to the hardware.
>
>
> So from a technical point of view streams is dead. There are people who
> worked on streams for years at companies like Spider, who specialised
> in making streams go as fast as is possible who will tell you it doesnt
> go fast enough and equally importantly you cannot make it scale if you
> want to be top of the pile.
So, STREAMS is definitely _not_ dead. It is my understanding that HP/UX has the
fastest web servers around, according to benchmarks, and is all STREAMS based
TCP/IP.
>
>
> Thats the technical status.
>
> > isn't the most important issue. If I had a choice between _no
> > application_ and a _slow application_ which met my critical needs,
> > I'd choose the latter 100% of the time. Would you?
>
> The Linux kernel is a technical project. Streams are "not interesting"
> technically. Productization is a vendor issue.
I thought that this was supposed to be a technical explanation, not a political
one. You are making an assertion of power here. Other folks want to use Linux to
produce commercial products. To them Linux is not a technical project any more
than SCO or Solaris is a technical project. It is a platform for their
applications.
>
>
> > a mistake to tie "NetWare on Streams" with "NetWare performance".
> > The two are entirely unrelated.
>
> Indeed - netware is fast "despite streams" and "despite the netware
> protocol weaknesses" - its a victory of sheer human stubbonness and hacking
> skill over technically poor tools. You may care to benchmark netware 3
> versus netware for unix on pure packet turn around time for a null NCP
> operation. Now compare it with 2.1.x knfsd (socket based kernel code)
> turning around an NFS no-op.
Do you have such benchmarks? Are they published somewhere?
>
>
> You will find it interesting.
Yes. I am sure that we would.
>
>
> > A: Because certain extensions to the kernel must be made in order to
> > support the Streams loadable module. For example, Streams
> > introduces some new system calls which are NOT present in the base
> > kernel (e.g. putpmsg, getpmsg). The kernel system-call table must
> > be modified to support these Streams entry points.
>
> Syscall numbers you didnt register with Linus as far as I can tell, which
> means since 2.2 uses more numbers you are likely to see breakages. Irrespective
> of any streams issues those two calls as NULL hooks you could get dropped
> into 2.1.x. Ask Linus - he did it for AFS. I cannot put anything like that
> into 2.0 until it has official 2.1.x syscall numbers from the man himself
> or I cause a back compatibility monster with a syscall numbering collision.
I have asked Linus on two occasions with no reply to either request.
>
>
> > that the kernel changes required to support a loadable Streams
> > module are strikingly tiny. But there is such a "religious"
> > opposition to Streams among _kernel developers_ that they refuse to
> > allow even these tiny patches into the "base kernel". They seem to
>
> It is entirely a technical opposition.
I disagree. All you have to do is put in the hooks. They are passive, tiny and do
not affect kernel operation of non-STREAMS in any way. From there on the "contest"
is technical. Right now it is 100% political. Some of us want the kernel hooks
and the keepers of the kernel exercise their power to keep them out of the kernel.
>
>
> > fear the introduction of support for a Streams module as such a
> > terrible "pollution" of their kernel that they have not and
> > apparently will not allow it to happen. So Caldera is stuck--the
>
> Putting support for something in the kernel implies a maintenance commitment
> that in this case is not there. Ask Caldera or any vendor about the effect
> of shipping a package you cant maintain. They can write in big letters
> "this package is an add on its not supported", it makes no odds. So there
> are real issues adding anything to a kernel - especially as its damned
> hard to remove something from the kernel, even when its way more dumb than
> say streams
>
> That said I see no reason why Caldera shouldnt ask and get a pair of syscall
> numbers from Linus they can hook.
I repeat, since you repeat: I have asked twice and received no reply to either
request.
> > A: I've been truly amazed at the "group opinion" on this subject.
>
> If you were technically aware of whats going on in networking you wouldnt
> be. Streams is being dropped globally.
This is an assertion without evidence. With Sun, HP and SCO all still using
STREAMS then it is most assuredly not being dropped globally.
> Streams was originally a victory
> of standards people over sanity, its now being blasted into oblivion because
> 1. Networks have sped up by a factor of 100 in 3 years - Memory hasnt
> 2. Network performance is the hottest checklist item and its going to grow
> faster and faster.
This may be an argument against dropping everything and changing Linux networking,
i.e., TCP/IP code to STREAMS. But it is not a valid or even germane argument
against providing a STREAMS executive, sans TCP/IP, for people who need it to
implement standards based protocol stacks having nothing to do with TCP/IP.
>
>
> > Most people say that opposition to Streams is on technical grounds,
> > but I believe the real opposition is a political one. Many people
>
> I've never seen Linus with a political agenda. And even the people who get
> political about streams (eg Larry McVoy) do so from a technical base point.
Then why won't he put in the STREAMS syscall hooks? That is all it takes to make
this a technical, rather than political, issue.
> <snip>
>
> > The fascinating thing going on here is the fear of the "success" of
> > Linux: If someone wrote a "major application which depended on
>
> It wouldnt be a success - it would be an app that screws the future of
> the Linux networking stack. Right now we are the most shit hot piece of
> PC networking software on the planet. The only people who can touch us
> are FreeBSD (who also dont do streams).
I don't think that I have seen a single posting calling for a STREAMS based
networking implementation in the Linux kernel. If there has been such a posting,
please e-mail it to me, I would be interested to read it. What people really want
is for the LiS STREAMS executive to be distributed with the kernel source so that
they can port their existing STREAMS drivers to Linux.
>
>
> Having an application that is streams dependant that makes it hard to break
> the streams stuff isnt acceptable from a purely technical standpoint. Nor is
> it good for the long term future of Linux.
Just don't step on our syscalls and you won't break LiS.
>
>
> What it means 3 years down the line is Linux would be bottom of the webstone
> benchmark and all the nice "linux is fast" graphs that sell Linux webservers
> will be gone, dead and history.
Non sequitur. The request is _not_ to replace TCP/IP with STREAMS.
>
>
> Linux is _technically superior_ - that is its fundamental superiority. The
> core Linux product must continue to be so and the Linux core team agenda
> is purely technical superiority
Another non sequitur. LiS will not impact any of the above.
>
>
> > the masses. (Not to mention David's unsupported assertion that the
> > mere presence of Streams in the kernel cause the kernel itself to
> > slow down--this just ain't so.)
>
> It does. We cannot do zero copy page flipping in a streams environment.
But, you see, the people who want STREAMS as a kernel feature don't want to do zero
copy page flipping.
> When
> we do that the GCOM code _will_ probably break.
No. Not unless you force that feature onto every driver via the read and write
syscalls. LiS _defines_ the getpmsg/putpmsg syscalls and will handle user data in
its own way.
> I suspect it'll break in a
> fixable way where it'll be even slower again but with 1Gigabit networking
> once the cards support it , non zero copy networking is _not_ an option if
> we want to stay top of the pile.
Another non sequitur. We are _not_ talking about networking here.
> So we will end up breaking the GCOM stuff
> possibly pretty badly although I hope not, there is no malice in breaking
> of things.
Since our LiS is _not_ networking code, you can do anything you want to the
networking code and it will not affect LiS, let alone break it.
>
>
> Another very worrying issue is field of interest in the support. Caldera
> ship only x86 Linux. Has anyone ever even verified the GCOM streams code
> is 64bit clean big and little endian, alignment clean, copes with ARM
> packing rules and all the other little portability wonders the mainstream
> code has to meet.
This is really up to the STREAMS interested parties. All _you_ have to maintain is
to allocate the syscalls and refrain from stepping on them in the future. Once
that is done it is truly just a technical issue. If someone wants to port LiS to
Alpha they will do so and provide the patches for what they had to do.
>
>
> > I disagree with David's assertion that Streams will "creap" [sic]
> > like a "fungus" into the rest of the kernel. Streams has a
> > well-defined kernel interface that is not likely to change much
>
> No streams does NOT have a well defined kernel interface.
It is precisely the same well defined interface used by any loadable module.
> It has a poorly
> defined set of interactions with core Linux data structures.
LiS has no more data structure interfaces with the kernel than any other loadable
module. It does not go mucking around in the kernel's data structures. It handles
"struct file" and "struct inode" pointers no more than any driver in
/usr/src/linux/drivers/char. The STREAMS executive does not contain even a single
reference to the skbuff structure.
You have no evidence for your assertions. Have you looked at the LiS source code
to verify your statements?
> You may not
> be a good enough programmer to see that
I'm a good enough programmer to see what the LiS/kernel interface is. I
implemented LiS.
>
>
> Streams depends on the sk_buffs in the kernel. In a zero copy world those
> buffers may well just not exist any more
Another non sequitur. LiS STREAMS contains an add-on driver to adapt a DLPI
conformant STREAMS driver below standard Linux TCP/IP by bridging between the two
styles. This add-on driver, which is an optional, not required, part of LiS is the
ONLY code in LiS that even references an sk_buff.
>
>
> > it's maintained by some nice guys at Gcom, NOT the _kernel
> > developers_. Linux Streams (LiS) has a lifetime of its own
>
> For how long. Who maintains it if Caldera pull out of Linux to concentrate
> on DOS only. Who maintains it if Caldera decide GCOM are charging too much.
Gcom maintains LiS, not Caldera. Gcom does not charge Caldera (or anyone else)
anything whatsoever for the maintence work that we do to LiS. Bug reports from
Caldera are always well researched with constructive suggestions, so this is not
burdonsome for us.
> Are Caldera committed to 2.2 support of it, have they discussed getting
> the syscall numbers (which is all the actually need) from Linus ?
I repeat: I have asked Linus on two occasions to allocate these syscall numbers
and have had no reply whatsoever to my queries either time.
>
>
> > A: This remains to be seen, but a couple come to mind. Firstly,
> > Caldera's NetWare for Linux (NW4L) would definitely NOT be on Linux
> > were it not for Streams. You can decide for yourself whether or
>
> These are entirely non-technical issues, and you seem to be a bit short
> of actual examples except the netware client, which has a free version
> shipped in the standard kernels.
The Gcom protocol drivers are a commercial product which would not exist on Linux
but for LiS STREAMS. There have been over 300 downloads of LiS from our FTP site.
A number of these have lead to porting of commercial drivers from Solaris and other
STREAMS based Unix environments to Linux. None of these projects would have taken
place without the existence of LiS. This _is_ a technical issue for the people who
want to port their software: No STREAMS, no port, period.
Just because Linux has a free IPX is no argument for the non-applicability of
Caldera's work porting branded Netware to Linux.
>
>
> The decisions people like Linus and Davem make on what goes into the
> kernel are purely technical ones.
Then what is the technical reason not to allocate two system calls for LIS?
> If Caldera think there is a market in
> shipping a modified "streams aware" kernel good for them. Streams is a
> marketing and productization issue not a technical issue.
That is just an assertion. It is what makes this a political issue rather than a
technical issue. You are in a position of power; we are not. What you say goes;
we are out of luck.
> Streams ran out
> of technical arguments a very long time ago.
That is another pure assertion without facts to back it up. Again, political. You
speak from a position of power so you can make these statements with no challenge.
> Right now every vendor is
> trying to figure out how to get streams OUT of their box while keeping
> legacy API compatibility code from bloating the kernel another 200 K.
Not so. Sun, HP, SCO all have STREAMS very much IN their boxes.
>
>
> We don't want to put that 200K in.
Straw man. Two system calls does not equal 200K.
> Maybe to Caldera its a worthwhile
> commercial product. As I've said - reserve your syscall numbers I cannot
> see an opposition to that. Thats the advice I gave in 1996 or so when
> this first came up.
So we are all agreed: Linus should allocate syscalls for us and then the LiS fans
can take it from there.
See, that wasn't so bad, was it?
-- Dave
>
>
> Alan
> ================================================================
>
> Rusty.
> --
> .sig lost in the mail
From: Andi Kleen <a...@muc.de>
Subject: Re: STREAMS?
Date: 1998/08/04
Message-ID: <m3g1fdqst6.fsf@fred.muc.de>#1/1
X-Deja-AN: 377715111
Distribution: world
Sender: a...@fred.muc.de
References: <35C01137.592AF279@ind.tansu.com.au>
<83yatak0dd.fsf@kevin.rustcorp.com.au> <35C64666.AAF2E719@gcom.com>
Organization: [posted via] Leibniz-Rechenzentrum, Muenchen (Germany)
Newsgroups: comp.os.linux.development.system
David Grothe <d...@gcom.com> writes:
[ Just a short comment, I don't want to start these flamewars again ]
> (David Grothe is one of the co-authors of LiS STREAMS.)
[ Replying to a pasted old mail of Alan Cox] - if you want to reply
to Alan you should send it to him directly, because he does not read
this newsgroup.
[...]
>
> >
> >
> > Streams are technical very flawed and not a good thing to put in
> > a kernel. Indeed our Solaris, SunOS, SCO etc emulation layers
> > turn streams into sockets as fast as possible. (note btw ibcs2
> > does this -without- kernel patches), as could Caldera. Although
> > for the syscall registering issue there may be a sane reason for a
> > registering those. Ask Linus.
>
> I have asked Linus twice to register the LiS system calls. No reply either time.
Try resending it, he seems to often lose mail. You could also put it into
jitterbug (http://samba.anu.edu.au/linux-patches/)
-Andi
From: Keith Nichol <kei...@ind.tansu.com.au>
Subject: Re: STREAMS?
Date: 1998/08/05
Message-ID: <35C795E6.16D6BCA8@ind.tansu.com.au>#1/1
X-Deja-AN: 377975457
Content-Transfer-Encoding: 7bit
References: <35C01137.592AF279@ind.tansu.com.au> <87soji25nd.fsf@loki.wkstn.nix>
<6prd28$hal$4@zeus.rbi.informatik.uni-frankfurt.de> <6prfuj$d1g$1@supernews.com>
<Xsfw1.1091$se7.8970071@news.rdc1.ct.home.com> <87sojgzqnz.fsf@loki.wkstn.nix>
Content-Type: text/plain; charset=us-ascii
Organization: Telstra Corporation
Mime-Version: 1.0
Newsgroups: comp.os.linux.development.system
Nix wrote:
> According to Alan, Linus and several others, the official position
> (as much as there ever is one) is `no'.
>
> I don't think there is *one* regular linux-kernel contributor who
> likes it (and certainly *this* lurker doesn't.)
So to get this straight there is resistance to inclusion of STREAMS in the
Linux kernel from those most responsible for it and therefore we are *not*
likely to see STREAMS included in any "standard" kernel, be it stable or
development. Correct?
I'm not up on the pro- and con- arguments and don't want to start a
philosophical war, I just wanted to know whether I *need* to make a new
kernel should I want STREAMS or whether it's likely that LiS will be
included -- ever. That question's been answered against LiS, thanks.
Sorry if this is behind the rest of the thread: I'm at least three days
behind on my news feed.
Cheers
Keith
--
Keith Nichol | Address : Level 2, 175 Liverpool St,
Telstra Intelligent Network Platforms | Sydney 2000, Australia
| Phone : (+61) 2 9206 3429
mailto:kei...@ind.tansu.com.au | Fax : (+61) 2 9281 1301
From: Andi Kleen <a...@muc.de>
Subject: Re: STREAMS?
Date: 1998/08/05
Message-ID: <m367g8fgrf.fsf@fred.muc.de>#1/1
X-Deja-AN: 377985252
Distribution: world
Sender: a...@fred.muc.de
References: <35C01137.592AF279@ind.tansu.com.au> <87soji25nd.fsf@loki.wkstn.nix>
<6prd28$hal$4@zeus.rbi.informatik.uni-frankfurt.de> <6prfuj$d1g$1@supernews.com>
<Xsfw1.1091$se7.8970071@news.rdc1.ct.home.com> <87sojgzqnz.fsf@loki.wkstn.nix>
<35C795E6.16D6BCA8@ind.tansu.com.au>
Organization: [posted via] Leibniz-Rechenzentrum, Muenchen (Germany)
Newsgroups: comp.os.linux.development.system
Keith Nichol <kei...@ind.tansu.com.au> writes:
> Nix wrote:
>
> > According to Alan, Linus and several others, the official position
> > (as much as there ever is one) is `no'.
> >
> > I don't think there is *one* regular linux-kernel contributor who
> > likes it (and certainly *this* lurker doesn't.)
>
> So to get this straight there is resistance to inclusion of STREAMS in the
> Linux kernel from those most responsible for it and therefore we are *not*
> likely to see STREAMS included in any "standard" kernel, be it stable or
> development. Correct?
>
> I'm not up on the pro- and con- arguments and don't want to start a
> philosophical war, I just wanted to know whether I *need* to make a new
> kernel should I want STREAMS or whether it's likely that LiS will be
> included -- ever. That question's been answered against LiS, thanks.
Not everything needs to be distributed with the core kernel distribution.
For example iBCS lives happily for years now as an external module, the
same do the PCMCIA services etc. I think LiS can just do the same.
It is only required to add a few minimal hooks to the kernel (for example
statically allocated syscall numbers) to ensure that the LiS module can
be build and loaded without changing the core kernel. 2.1.115-pre already
contains the syscall allocations, and I expect 2.0.36 to contain them too[1]
The syscall number allocation is especially important, because it is required
for binary compatibility of STREAMS applications [which one - Caldera's port
of NetWare for Unix - is already shipping]
-Andi
[1] This does not mean that LiS will run without patches on 2.0, because
it needs poll(), but in the upcoming 2.2 there are good chances that LiS
will just work fine without any additional kernel patches.
|