lkml.org 
[lkml]   [1998]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Streams and Linux
Date
Alan Cox enscribed thusly:

> [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"

That plus someone remarked, not too long ago, that the way streams
has been implimented and used (non-Linux - Solaris use and implimentation)
the term is more aptly described as "sewers" not "streams". The reference
was made to the fact that there were cases where streams were missapplied
in cases not appropriate. Those are, of course, the cases where we hear
the most noise about the lack a streams....

:
: - Text deleted...
:

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

I did some work with a speech recognition product on Solaris that
"tee'd" the keyboard and mouse streams down in the kernel. That probably
gives me a unique and biased opinion about streams in general that probably
is NOT applicable to the general streams programer. My opinion is that
the has got to be a better way and, so far, I have yet to find an application
where there wasn't.

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

Choice between no application or slow application? How about a
slow application and one that is properly implimented? I have yet to
find anything that could not be implimented without burdening it with
streams modules...

> The Linux kernel is a technical project. Streams are "not interesting"
> technically. Productization is a vendor issue.

I "may" differ with Alan on this point. Streams do have some
"interesting" aspects. However, they are NOT aspects that I would want
in the critical path of an application!

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

Touche' !!!!

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

You have to wonder why they haven't if it really is all that
important.

:
: - More deleted text...
:

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

Hmmm... Another point of disagreement with Alan. I thought it
was a victory of academia (gee that sounds like a nice theses) over
practicality (how the $#!#$#@ do we make this #@$! thing work?!?!) rather
than standards over sanity.

> > Most people say that opposition to Streams is on technical grounds,
> > but I believe the real opposition is a political one. Many people

Dream on! I've had to work with them on Solaris (vs SunOS) on a
very personal level.

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

They are self fullfilling...

While I was working on my Solaris drivers, I had numerous
entertaining instances where the system was left incapable of booting.
My only recourse was to boot from the SunOS (4.x) CD and repair the damage
I had done (removed the driver that interacted with the keyboard stream)
and then reboot. My "kernel guru" contact in the systems group at Sun
remarked that it was a good idea to cherish and preserve my SunOS CD's for
that very purpose. My problems actually extended to the interaction between
the streams modules and the mutex locks in the kernel but taught me a heathy
distrust of streams...

:
: - Remainder deleted...
:

Mike
--
Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com
(The Mad Wizard) | (770) 925-8248 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.034 / U:4.832 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site