Messages in this thread | | | From | "Paul Fulghum" <> | Subject | Re: Synchronous board drivers | Date | Thu, 15 Jul 1999 09:18:54 -0500 |
| |
From: Paul Mackerras <paulus@cs.anu.edu.au>
> No, I would see these things as being queried, negotiated and > specified by pppd, not the kernel ppp layer. Pppd would talk directly > to the channel via ioctls on a file descriptor which has the char > device for the channel open (not a fd which has /dev/ppp open).
I was confusing the two. I was trying to envision the interface from the channel driver's view, which I still understand to be an ioctl interface for control by the entity that implements the negotiation.
The PPP options could be specified in the ioctl as a variable length block encoded in the same fasion as an LCP frame (starting with the LCP protocol ID). This way as new RFCs are added, the format of the call would not change. I'm not suggesting any LCP type negotiation, just a simple list of options that are supported or have been negotiated.
> The channel code (e.g. the sync board driver) is at least going to > have to have an ioctl that tells it to connect itself to ppp unit n. > When it gets that, it will call register_ppp_channel() (e.g.) and then > it will call ppp_channel_input() with skbuffs containing received > frames, and its ppp transmit routine will get called back with skbuffs > containing frames to transmit.
Where does the 'frame' begin? If the media specific PPP options are implemented in the channel driver, then I would assume it starts at the protocol ID field?
If possible, inform me any early implementations, so I can add these interfaces to our driver and help with testing.
Paul Fulghum paulkf@microgate.com Microgate Corporation www.microgate.com 9501 Capital of Texas Hwy Austin, Texas 78759 (512)-345-7791
- 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/
| |