> 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/