The isdn synchronous ppp (drivers/isdn/isdn_ppp.c) works like this, several
ippp connections are controlled by a single /dev/ippp device. (It is, however,
possible to bind groups of isdn ppp channels to different
/dev/ippp[0-9][0-9] devices which allows, e.g., to control different groups of
channels by different ipppd processes configured for different access policy).
Thus, the approach described above is not only fine in theory, it also
has proven to work very well in practice. (It might even allow to re-use
parts of the isdn_ppp kernel and daemon code for the implementation).
> The generic ppp layer would have a standard interface to
> communications channels. There would be several types of channels
> such as async serial lines, HDLC lines, ISDN, frame relay, or sockets
> (e.g. for L2TP or PPP over ethernet).
>
The question is how the channel interface should be designed. There are
curently three different ppp implementations in the kernel
drivers/{net/{ppp.c,sync_ppp.c,isdn/isdn_ppp.c}
ppp.c and isdn_ppp.c use their own interfaces which is closely related
to the hardware type.
sync_ppp.c uses the standard linux packet handler (low layer must be
a network interface which sets the skb's type to
PPP and passes it upward by netif_rx()). The latter has the advantage
that it is the most flexible (not hardware dependent in any way)
and avoids creating yet another kernel-internal interface. The
disadvantage is that it does not allow to pass link state changes
(i.e. tty hangup) to the upper layer and that each packet passes
netif_rx two times.
> The channel code is basically responsible for sending and receiving
> ppp frames. It can tell the generic ppp code when its underlying
> medium has gone away (e.g. hangup on an async tty). Pppd would talk
> to the channel directly in a device-dependent fashion, e.g. for an
> async tty, it would set it to ppp line discipline and do ioctls on it.
>
>From the experience gained with isdn_ppp (ipppd also needs some
isdn4linux(device)-specific extensions) it should be noted that building
device-dependent knowledge into pppd creates a maintnace problem.
As pppd was also used outside linux, isdn4linux-specific
extensions could not merged back into pppd sources. Thus, it was necessary
to maintain an own version of pppd for isdn -- a situation which is clearly
undesireble. The problem will probably become worse when even more
linux-specific ppp-hardware types are to be supported. Thus, it seems to be
worthy to carfully think about the design of a general, device-independent
communication protocol that allows to control connections through /dev/ppp.
>
> I think that to the extent that this is a "mid-layer" approach rather
> than a "library" approach, it is because the desire to do multilink
> pushes it in that direction. The thing that gets packets to transmit,
> i.e. the ppp network interface unit, gets to choose which of several
> channels to use to send it (or if the packet is to be split between
> channels), and also whether the packet is to be compressed at the
> bundle level. It seems to me that this inevitably makes the ppp
> network interface unit a mid level, with the channels being a lower
> level.
Just a brain storming question: Would the 'struct datalink_proto' (include/net/datalink.h) be an appropriate object to implement a general sync_ppp layer?
Henner
-
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/