------=_NextPart_000_0047_01BEC892.90D23BF0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
From: Paul Mackerras <paulus@cs.anu.edu.au>
> The address and control bytes are really part of the medium-specific
> encapsulation. The data will be in a skbuff with enough headroom that
> the channel code can easily add them if it needs them.
>
> Of course, 2 bytes is nothing, really, and if it makes life easier for
> most types of channel I don't mind putting them in. I thought they
> were really only used for async serial channels though (and then
> usually compressed out anyway). On balance I thought it was cleaner
> and neater not to have to worry about those 2 bytes in the generic ppp
> code.
>
> Paul.
Paul:
The generic ppp code controls the LCP, but the LCP is used to negotiate
media specific options, such as AFCF compression, or numbered transfer
mode (RFC1663).
If the generic ppp code deals with data starting at the ppp protocol ID
field,
how do you envision communicating the results of the LCP negotiation
to the channel which would implement the option.
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.
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?
Just curious,
Paul
Paul Fulghum paulkf@microgate.com
Microgate Corporation www.microgate.com
9501 Capital of Texas Hwy
Austin, Texas 78759
(512)-345-7791
------=_NextPart_000_0047_01BEC892.90D23BF0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">