> Almost every "mid layer" in the kernel has proved to be a mistake in the
> long term. SCSI is the classic example
True. That being so I'd like to run my current thoughts for
redesigning the ppp support in the linux kernel past people on this
list.
The aim is to reduce code duplication and make it easy to do multilink
over a variety of different types of communications media.
My plan was to have a generic ppp layer which handles the following:
- the pppX network interface units
- packet compression and VJ TCP header compression
- multilink
Pppd would talk to and control the generic ppp layer through a
/dev/ppp device which would be a misc. character device. Part of the
motivation for having a /dev/ppp is that when an async tty hangs up,
pppd immediately loses the ability to use the fd to the tty for
talking to the kernel ppp driver. Having /dev/ppp would give pppd a
more robust mechanism for talking to the kernel ppp driver.
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 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.
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.
Comments?
Paul.
-
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/