Messages in this thread | | | Date | Fri, 9 Jul 1999 01:09:50 +0200 | From | Henner Eisen <> | Subject | Re: Synchronous board drivers |
| |
>>>>> Andi Kleen <ak@muc.de> writes:
>> Would a new packet type like PACKET_CONTROL would be >> appropriate?
> Oh no, please no STREAMS.
No, I didn't want to introduce STREAMS through the backdoor.
The reason why I was asking for a PACKET_CONTROL packet type was that some higher level protocol need to control state of low layer protocols. If the low layer protocol is implemented in firmware of an intelligent IO board, then this control information needs to pass the netdevice boundary. The kernel currently does not support this. X.25, which needs such control, currently passes the control info by means of an additional byte prepended to the skbuff (Documentation/networking/x25-iface.txt). However, this results in some incosnstencies related to the skbuff header pointers: skb->data and skb->nh are different when the skb passes the device boundary. The additional (artifical) control byte neither belongs to to the X.25 protocol nor to the link layer (it needs to be stripped by the device before it can add its datalink headers).
With a general ppp layer, a similar problem arises if the upper layer (ppp) wants to control the lower (link) layer accross netdevice boundaries. Thus, I was thinking about whether an official link control mechanism could be provided by the kernel. One possibility would be a dedicated packet type for control frames. The skb->cb[] trick would be another. But would the latter be abuse again or is the cb[] field intended for such use?
Henner
- 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/
| |