Hmm, so you want to be able to call the hard_header constructor
for a different device. This makes sense. However, I think that
David and I are currently planning to move toward constructing
the hard header lower down, rather than at the IP layer. Ideally
headers should not be tacked on until the packet is about to go out.
This means that things like the shaper don't need to know what kind
of headers the lower layer devices are going to stuff onto it.
Really we are thinking of having a skb structure as a chain of
data chunks. Normally things would look something like:
skb_header --> [eth header + IP header + tcp header ] --> [data]
But if lower level protocols need to tack on extra headers we might see
longer chains like:
skb_header --> [eth header] --> [encap header] --> [IP header + tcp header]
--> [data]
We're still working on details, but this would clean up a lot of the
trouble I'm trying to sweep under the rug right now in the 2.0.31 kernel
with regard to variable length headers (SACK, ISDN compression).
The tunneling device is latest trouble maker for me there, but EQL,
ISDN and PPP are also problems. I've almost got a way to hide all the
problems without having to rewrite the IP layer, but it's getting
really nasty, and I don't like the way it looks at all.
-- Eric Schenk www: http://www.dna.lth.se/~erics Dept. of Comp. Sci., Lund University email: Eric.Schenk@dna.lth.se Box 118, S-221 00 LUND, Sweden fax: +46-46 13 10 21 ph: +46-46 222 96 38