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