Messages in this thread | | | Subject | Re: Synchronous board drivers | From | Krzysztof Halasa <> | Date | 06 Jul 1999 12:04:42 +0200 |
| |
Paul Mackerras <paulus@cs.anu.edu.au> writes:
> That is actually exactly what I meant, obviously I didn't explain it > well enough. The generic ppp code would give raw ppp frames to the > channels, and get raw ppp frames from them. A raw ppp frame would be > just the 2-byte header (PPP protocol number) and the data, in a > skbuff. The channel code would do any encapsulation, framing, > escaping, etc. that is needed for that type of channel.
Why not use HDLC frames? That addds 2 bytes to the header, but would be consistent with other protos:
RFC 1662, 3.1. Frame Format
A summary of the PPP HDLC-like frame structure is shown below. This figure does not include bits inserted for synchronization (such as start and stop bits for asynchronous links), nor any bits or octets inserted for transparency. The fields are transmitted from left to right.
+----------+----------+----------+ | Flag | Address | Control | | 01111110 | 11111111 | 00000011 | +----------+----------+----------+ ^^^^^^^^^^^^^^^^^^^^^^^
+----------+-------------+---------+ | Protocol | Information | Padding | | 8/16 bits| * | * | +----------+-------------+---------+ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+----------+----------+----------------- | FCS | Flag | Inter-frame Fill |16/32 bits| 01111110 | or next Address +----------+----------+-----------------
Of course it wouln't include flags (0x7E) nor FCS, as they are usually done in hardware/firmware. -- Krzysztof Halasa Network Administrator
- 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/
| |