Messages in this thread | | | Date | Wed, 14 Jul 1999 23:31:44 -0500 | From | Paul Fulghum <> | Subject | Re: Synchronous board drivers |
| |
Paul Mackerras wrote:
> > 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/
| |