> Stop. The generic PPP layer should have one frame type - PPP. It might
That is actually exactly what I meant, obviously I didn't explain it
well enough. The generic ppp code would give raw ppp frames to the
channels, and get raw ppp frames from them. A raw ppp frame would be
just the 2-byte header (PPP protocol number) and the data, in a
skbuff. The channel code would do any encapsulation, framing,
escaping, etc. that is needed for that type of channel.
> be given a notice if the layer is reliable or not, and if it is
> dialable.
I don't see that the generic ppp code in the kernel needs to know
that. Any dialling would be done by userspace (e.g. pppd) talking
directly to the channel. If we want to implement PPP reliable mode on
unreliable channels, that should be done in a library called from the
channel code.
The generic ppp kernel code does need to know when the channel goes
away, and it would be useful to have some indication of the current
transmit queue length inside the channel for multilink load-balancing
purposes.
> > 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.
>
> That does seem kind of unavoidable. On the other hand for channels not
> part of your multilink bundling and the like I can still register myself
> a sync device for say a smart firmware driven PPP and interact in all other
> ways as if I was using your layer.
If you have a smart firmware-driven PPP board, then wouldn't it be
doing the ppp negotiation itself, thus removing the need for pppd and
the kernel ppp driver? Wouldn't it look much more like an ethernet
interface? What part of the generic kernel ppp code would still be
useful with such a board?
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/