>> > Yes. Its a mismatched assumption rather than a bug.
>> >
But isn't it documented (although somewhat hidden, look at the comments
in net/packet/af_packet.c) that network layer should reserve
dev->hard_header_len even if device has no hard_header() method?
This `documentation' also seems to indicate that
dev->hard_header==NULL in combination with dev->hard_header_len != 0
means that the device uses a link layer which needs space, but which is
not meaningful from outside. My understanding of this was that PPP or
other stateful link protocol can use this. (They need to build the header in
dev->hard_start_xmit() because header might not only depend on
Network Layer address/protocol but also contain sequence numbers,
time stamps, or depend on link compression state which might
chage even if identical network layer frames are re-trasmitted).
>>
>> OK, what should we do, insert a (dummy) dev->hard_header()
>> method in the isdn driver as first workaround ?
Alan> For 2.2.x yes simply because it doesnt affect anything non
Alan> ISDN if there are subtle suprises about changing the core
Alan> code. For 2.3.x it wants fixing in the main code IMHO
Karsten, don't worry! isdn_ppp (as well as the sync_ppp driver)
already has a hard_header() method and thus won't be affected.
(It even reserves header space there for ppp since the
first 2.0.3x kernels because network core maintainers asked us
to do so in order to work around a bug in fragmentation code.
That bug should be fixed in 2.2.x, but the work around is still in the
isdn_ppp driver.
Only async ppp (2.2.x) or the ppp_generic (2.3.x) driver have no hard_header
method and could thus be affected.
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/