lkml.org 
[lkml]   [1999]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Synchronous board drivers
From
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.159 / U:0.904 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site