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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/