> > 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.
>
> Ok.
>
> > 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
>
> Yes. However two things apply here that are important
>
> 1. It may do PPP, but if I flip it to X.25 it may not do X.25, so the
> board itself needs a control of how it hands packets around.
>
> 2. I may want to be able to add a board specific ioctl to pick hardware
> (low cpu overhead) v software (multilink, cool feature set) PPP
My only comment on this, mixed systems. For example, I use a
fair number of Sangoma S508 units, they will do Cisco HDLC, SyncPPP,
X25, and Frame in *firmware*. It would however be nice to piggyback
in some cases, such as running kernel ppp over frame relay (ppp
session bound to a particular PVC/DLCI) (with the frame being done in
card firmware). Customers are needing PPP over frame support for IDSL
service, as few of them can talk native frame and depend on the telco
dropping their syncppp session onto frame and giving it to me via the
frame cloud. As of now it looks like I am stuck picking up a Cisco to
support this (a very sad thing, as to date ALL my routers of any type
are Linux based and I am very, very happy with them.
----
First Law of System Requirements:
"Anything is possible if you don't know what you're talking about..."
-
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/