On Mon, 1 Nov 1999, Arnaldo Carvalho de Melo wrote:
> 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,
^^^^^^
hardware
> 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
>
|