> > how do you envision communicating the results of the LCP negotiation
> > to the channel which would implement the option?
>
> Each channel will have to implement some way for user-space to get to
> it other than through the ppp layer. For async ttys this is easy
> because you have an fd open to the serial port. Other sorts of things
> will have to have a character device or something. Then pppd will
> tell the channel what to do via an ioctl on the channel itself.
>
> > Or for that matter, how does the channel communicate
> > which options it supports. For example, PPP over X.25 (RFC1598) does
> > not permit the AFCF compression option.
>
> Sure. Either pppd will just know that X.25 channels don't do ACFC, or
> it can ask the channel via an ioctl.
So, in a possible implementation, channel capabilities that support PPP
negotiated
options (such as AFCF compression) are queried by the ppp layer from the
channel
via ioctl, and the results of the LCP negotiation for supported
options are specified by the ppp layer back to the channel by ioctl.
> I think it is inevitable that pppd will have some channel-specific
> code in it. There is an argument for having different channels
> support a similar set of ioctls so as to minimize the channel-specific
> code in pppd.
>From what you suggest (and I agree), any options negotiated by the PPP
layer
which are defined by an RFC can be handled by the capabilities reporting
mechanism described above. Any media specific requirements that
do not effect LCP negotiation should be unknown to the PPP layer
(and controlled through a mechanism outside the scope of the PPP layer).
If you place channel specific code in pppd, then you must still
communicate
the channel type to pppd in some method similar to the capabilities
reporting.
> > If we wish to define a generic sync adapter interface which just exchanges
> > raw frames, does this imply a channel layer between such an interface
> > and the generic ppp? For example: one channel for synchronous unnumbered,
> > one for sync numbered, and another for X.25. All of these channels have
> > the generic sync board interface on the bottom and a generic ppp interface
> > on top?
>
> The driver for the sync board would have to know how to cope with
> these different protocols. The code for doing these different
> protocols could/should be put in a library so it can be used by
> various drivers.
>
> How does that sound?
>
> Paul.
I think there is some confusion in describing a generic sync board
interface
vs. a generic PPP interface. The generic sync interface deals with HDLC
frames,
where the user of the sync interface specifies address and control field
(and
any link layer procedures such as LAPB/LAPD/LAPF etc.)
The generic PPP interface should deal with PDUs starting with the
PPP protocol ID field.
There is still room for a layer that implements something like LAPB
with the channel interface on top and the sync interface below. For
simple
unnumbered information frames on synchronous HDLC, a generic sync driver
could implement the extra ioctls call for PPP capabilities reporting and
option
specification to avoid mid layer overhead.
Just my 2 cents. Whatever is decided, I'm perfectly happy to write to
the new interface.
-- Paul Fulghum paulkf@austin.rr.com- 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/