We have been discussing internally how to fix the PPP stack mess the Linux
kernel is currently in. At present there are at least 6 seperate PPP
stacks for Linux, each with thier own interface, advantages and
disadvantages.
We would like to see this mess cleaned up with a simple and elegant
solution that would allow all device types to access WAN services, such as
frame relay, x.25, PPP and SLIP, through a single interface. We are
thinking about adding our Babylon multilink PPP stack into the mix but
don't want to add yet another stack to the pile.
We have been tossing some ideas around and this is one I had. I'd like to
get some broader feedback on whether this idea has any hope of resolving
the aforementioned crap heap.
What I propose is to add a layer of abstraction between the hardware and
the TTY interface, in effect virtualize the TTY interface, through a WAN
device layer. Now before you flame, let me explain my reasoning.
At present, the serial driver implements a TTY interface, which uses a
line discipline to spike off PPP or SLIP packets to the network device
interface. What I suggest is having the serial driver (all external I/O
devices really - async, sync, ISDN, etc.) implement a WAN interface (layer
2 if you will) that supports a number of protocol based interfaces (layer
3) including TTY, PPP, SLIP, etc. Here's how it looks:
Existing:
+-------------+ +------------+
| PPP | | SLIP |
+-------------+ +------------+
| |
+-----------------------------+
| TTY |
+-----------------------------+
| |
+-------------+ +-------------+
| hardware | | hardware |
+-------------+ +-------------+
Proposed:
+-------------+ +-------------+ +------------+ +-------------+
| TTY | | PPP | | SLIP | | Other |
+-------------+ +-------------+ +------------+ +-------------+
| | | |
+---------------------------------------------------------------+
| WAN Layer |
+---------------------------------------------------------------+
| | | |
+-------------+ +-------------+ +------------+ +-------------+
| hardware | | hardware | | hardware | | hardware |
+-------------+ +-------------+ +------------+ +-------------+
Rational:
1. The TTY interface is good and works well
2. The TTY interface was never disigned for handling network data
3. The problem with PPP is not a shortcoming of the TTY layer
4. PPP is not a line discipline and shouldn't be implemented as such
5. Changing the TTY code is not a good idea
6. The WAN layer should be very light-weight with most of the
overhead absorbed by the layer 3 protocol handlers.
7. The WAN layer API needs to be clean and efficient but at the same
time flexible enough to handle a wide range of hardware.
The WAN layer acts essentially as a double-action data switch, switching
data between the hardware and the appropriate layer 3 protocol handler.
The switching decision is made based on two flags: l2_protocol and
l3_protocol. The user chooses the layer 3 protocol based on how they open
the device (more on this later). The hardware indicates it's layer 2
capabilities when it registers with the WAN layer (async, sync, hardware
HDLC, etc.), The WAN layer matches up the two layers and fills in the gaps
where they exists.
Take opening a serial port for PPP as an example. The user opens the
serial port in PPP mode by performing an open on the right inode. L3 is
set to PPP. The PPP handler knows it needs HDLC framing so checks the
capability of the device. Since a simple serial port can't do HDLC in
hardware, it sets L2 to RAW mode (this informs PPP that it needs to do the
L2 framing itself) and so on.
As for a TTY Layer 3, the WAN layer simply acts a proxy for the hardware.
** No change is made to the TTY code **. It simply looks as though the
hardware registered itself as a TTY device. One of the key benefits to
this scheme as I see it is that, from a driver writer's point of view, I
get n interfaces for the price of one. Since registration with the WAN
layer gets me a TTY, PPP, SLIP, X.25, Frame Relay, etc. interface. It also
retains compatability with existing TTY centric code, such as pppd, for
those who want to ease into a new method.
The distinction between what Layer 3 interface the user wants to use is
accomplished with Richard Gooch's devfs. Each device gets n number of
inodes, one for each layer 3 interface:
/dev
/tty
/serial
/0
/1
/ppp
/serial
/0
/1
/slip
/serial
/0
/1
...
I haven't actually worked out the details on this bit but it seems logical
enough.
I see this solution potentially fixing other problems as well:
1. Intellegent serial devices could be better exploited.
2. We could all concentrate our efforts on improving a single PPP stack
instead of implementing multiple copies of the same stack.
3. Drivers would be easier to write, bringing more hardware choices to
Linux.
Some problems that strike me immediately:
1. Detecting the layer 3 on incoming connections could be a trick.
Well, that's all I can muster at the moment. I'd love to hear any
feedback, comments, suggestions and yes, even flames you might have to
share on this topic.
Hopefully we can all come to some consensous on a way to solve this beast
and live happily ever after.
-----------------------------------------------------------------------
Erik Petersen +1 (416) 425-0600
SpellCaster Telecommunications Inc. erik@spellcast.com
http://www.spellcast.com Fax +1 (416) 425-0854
-----------------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu