On 1 Nov 1999, Henner Eisen wrote:
> >>>>> "Arnaldo" == Arnaldo Carvalho de Melo <acme@xxxxxxxxxxxxxxxx> writes:
>
> Arnaldo> point for such protocol, I've just added ARPHRD_HWX25 to
> Arnaldo> make my driver compile while such protocol proves to work
>
> I think we should also define a new protocol type (ETH_P_???) for
> packets passing to/from intelligent X.25 devicec which implement
> all three X.25 layers in firmware. IMHO, the current situation
> is not clean. ETH_P_X25 (which is even an offically registered
agreed
> ethertype) should be reserved for skb's containing X.25 PLP packets,
> where skb->data points to the head of the X.25 header when
> passing netif_rx(). Currently, that is
> not always the case: ETH_P_X25 packets received by a ARPHRD_X25 device
> have skb->data pointing to the link-layer control byte
> (Documenatiation/networking/x25-iface.txt) while ETH_P_X25 packets
> received via 802.2 LLC have skb->data pointing to the X.25 PLP header.
> Thus, current X.25 NL must analyse skb->dev->type for received
> frames and behave differently for ARP_HRDRD_X25 type as opposed to
> other HW type which I'd consider a layer violation.
> I think a clean solution should provide a distinct type, e.g.
> ETH_P_X25IFACE for packet with lapb control header. Then, we should
> also have a similar distict type (e.g. ETH_P_X25HWX25) for packets
> passed to/from intelligent X.25 devices.
>
> I also realized that if_ether.h contains a dummy type ETH_P_CONTROL.
> Does anybody know what it's intended for?
>
> No code (neither in net nor drivers/net) uses it.
>
> Maybe an alternative to the above would be to always use
> ETH_P_X25 for X.25 packets (ommiting the x25-ifaxe.txt
> 0x00 control byte) and using ETH_P_CONTROL for controling the lapb link
> state?
seems fine to me, this way we save a byte for data packets (common
case) and make the "prepare for future retransmition" (when we have to do
a skb_push(skb, 1) just to put the control byte back when the driver was
unable to send the packet to the driver right away) code a little simpler,
also with ETH_P_X25HWX25 we don't need to test skb->dev->type on packets
reception in af_x25.c.
> Henner
cool, I was trying just to hack the X.25 packet layer to make it work
without that much changes, but seems like we'll get a cleaner hack... ;)
- Arnaldo
|