DISCLAIMER: This is not a pro or contra streams article :-)
>>>>> "Ole" == Ole Husgaard <osh@xxxxxxxxx> writes:
Ole> 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???
>>
When I posted my message, I was almost sure to see a reply with
this magic word in it :-)
>> 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.
Yes, but the 'abstraction' is merily just a renaming, as the mechanism
needed to attach a ppp_channel to a socket will require exactly the
same functionality from the socket code.
Ole> Actually the modularity and configurability of STREAMS would
Ole> be really good for this kind of problem: The various pieces
Ole> of protocol code would be STREAMS modules and drivers running
Ole> in the kernel, and userspace programs could assemble them as
Anyway, I'd like to say that the proposed mechanism is different from
STREAMS. Just because it allows for tunneling a protocol over another
protocol does not make it STREAMS:
- Communication between the socket and upper layer protocol would be via
a function call interface similar to any other internal communication
between socket layers.
- No message passing with message queues or message dispatcher is involved
- The interface does not provide for controlling the connection. For
controlling the carrier connection, a user space program which creates and
controls the socket is permanently necessary. Only the data input and
output is linked to the upper layer of the tunnel.
As the control operations for the socket (connect/accept/ioctl/setsockopt)
are not needed to be called from kernel, there is no need make them working
from bh or interrupt context. Only the data input/output path needs to
be callable from kernel. And even if the protocol implementation requires
a process context for this, we don't need an artificial process for this,
because the process which controls the socket is already there.
Henner
|