Quotinig Brad Walker <bwalker@breakthru.musings.com>:


>> STREAMS is an easy programming layer, but SLOW.  STREAMS SUCKS!!
>>

>Based upon what??

Unacceptably poor network-stack performance, when compared to the
alternatives.   Any serious STREAMS-baseed UNIX vendors special-case
TCP/IP into non-STREAMS code.   The  performance of STREAMS

If you have to ask why STREAMS are slow, then that reflects poorly
on the basis of your technical judgement that NetBSD should switch
to using STREAMS.


And quoting Brad Walker again:

>Once again. Based on what. I would expect technical details not
>an appearance factor.

>I've written the serial drivers for Aurora Technologies serial boards.
>I was able to sustain 115.2 over several serial ports on a SS1. I wouldn't
>call that a performance problem.


I beleive the NetBSD project works like this: if you want to advocate
a change, then it's up to *you* to justify the change.  In constrast,
Brad is advocating a change and expecting everyone *else* to justfy
the satus quo.  Moreover, Brad's justification for this change is (by
his own standards) without "technical details": all we have from Brad
is "appearance factor".

That's just not how it works.
Oh yes, and (if there were any substantive technical discussion here) it
would belong on  tech-kern, or possibly tech-net.

last, there are also good technical reasons why we're saying "NO" to
STREAMS.  The performance problem of pure STREAMS-based network stacks
_are_ well-known to be poor.  Citing numbers from SGI or Solaris
kernels doesn't doesn't say anything about that problem, as (AFAIK)
both vendors' TCP/IP stacks divert TCP/IP traffic _out_ of the STREAMS
code more-or-less entirely, in the common case.