Thank you for your detailed review, Brian! I guess we have the same understanding on the "hard_header_len vs needed_headroom" part. I agree it is not well documented and is also confusing to driver developers. I didn't understand it either until I looked at af_packet.c.
On Tue, Jul 28, 2020 at 12:52 PM -0700 Brian Norris <briannor...@chromium.org> wrote: > > What's to say you shouldn't be implementing header_ops instead? Note > that with WiFi drivers, they're exposing themselves as ARPHRD_ETHER, and > only the Ethernet headers are part of the upper "protocol" headers. So > my patch deferred to the eth headers. > > What is the intention with this X25 protocol? I guess the headers added > in lapbeth_data_transmit() are supposed to be "invisible", as with this > note in af_packet.c? > > - if device has no dev->hard_header routine, it adds and removes ll header > inside itself. In this case ll header is invisible outside of device, > but higher levels still should reserve dev->hard_header_len. > > If that's the case, then yes, I believe this patch should be correct. This driver is not intended to be used with IPv4 or IPv6 protocols, but is intended to be used with a special "X.25" protocol. That's the reason the device type is ARPHRD_X25. I used "grep" in the X.25 network layer code (net/x25) and I found there's nowhere "dev_hard_header" is called. I also used "grep" in all the X.25 drivers in the kernel (lapbether.c, x25_asy.c, hdlc_x25.c under drivers/net/wan) and I found no driver implemented "header_ops". So I think the X.25 networking code doesn't expect any header visible outside of the device driver, and X.25 drivers should make their headers invisible outside of them. So I think hard_header_len should be 0 for all X.25 drivers, so that they can be used correctly with af_packet.c. I don't know if this sounds plausible to you. If it does, could you please let me have your name in a "Reviewed_by" tag. It would be of great help to have your support. Thanks!
