Paul Mackerras wrote:
>
> On Thu, 10 Feb 2000, Henner Eisen wrote:
>
> > Why not generalizing (essentially, it is just renaming) the paradigm
> >
> > 'attaching ppp channel to connected socket'
> >
> > to
> >
> > 'attaching/tunneling arbitray protocol over connected socket'
>
> Anyone for STREAMS???
>
> Seriously, if you want any chance of Linus/Alan/DaveM etc. being
> interested, you have to show some specific actual thing that this would be
> good for. Just saying `this is a nice abstraction' will get you nowhere.
Actually the modularity and configurability of STREAMS would be really
good for this kind of problem: The various pieces of protocol code would
be STREAMS modules and drivers running in the kernel, and userspace programs
could assemble them as needed by the particular application.
Interfacing with the existing Linux drivers and protocols at the datalink
layer is no problem: We have had code for this for years in the Linux STREAMS
project at http://www.gcom.com/LiS/.
There seems to be a few false assumptions about STREAMS in Linux floating
around, and I'll like to kill the most important:
Adding STREAMS to Linux does _not_ mean that existing network code would
have to be changed in any way, and the existing network code would _not_
become slower. In fact, Linux STREAMS runs as a module in a completely
unpatched 2.2 kernel.
Please note that I don't want to start a flame war about STREAMS or
advocate that the network code be all changed to STREAMS. But it would be
nice if kernel developers could use STREAMS when it has an advantage.
Regards,
Ole Husgaard
osh@xxxxxxxxx
PS: Some of you PPP guys might be interested in the QoS
anomalies I've observed when running PPP over async: Take a look at
http://www.sparre.dk/pub/linux/congestion/QoSproblem.html
|