> When writing the RFC-1051 if_arcsubr.c and the hardware driver, I
> looked at some Ethernet drivers and if_ether.c to get an idea about
> what I should need to do. I noticed that most Ethernet drivers put a
> (16 - sizeof(etherheader))byte padding at the beginning of the mbufs
> they copy the received packets to, to make the IP packet longword
> aligned. One of the authors of an ethernet driver mumbled, in a
> comment, s.th. about a NFS bug which makes it necessary to align the
> IP packet on longword boundaries.  Thats what I also did for arcnet.

hmm.  umm, it'd be interesting to know for what type of machine that
ethernet driver was written.  There shouldn't be any alignment
problems (other than efficiency) on m68k or i386 machines, because
unaligned accesses work fine.

also, since you can tell (by trivial inspection) the amount of padding
for each packet type, you could simply have a function that tells you
how much padding you need for that packet type, and copy the data into
an mbuf, padded by the appropriate amount...

> Now, if that is still necessary, I have to put 1 byte of alignment in
> for 1051-like packets, and 2 bytes for 1201-like packets. I can switch
> that on the link0 flag, but then I would punish other protocols which
> stay at 1201 encoding even if I use old style IP. I hope its more
> clear now. If i looked at the "system id" in the hardware driver, I'd
> be able to choose the correct padding, but then I would have to
> incorporate knowledge about what protocols are 1051 or 1201-like into
> hardware drivers. Or build an table into the if_arcsubr.c, which the
> hardware drivers would use.

you don't even need to build a table, you can have a simple function,
e.g. int arc_padding(u_char packet_type); which returned the number of
bytes of padding necessary.  it could consist of a short switch table,
defaulting to 0 bytes of padding.

It's also not really a case of adding bytes of _padding_, it's a case
of picking the right address at which to start writing your data...
(i.e. you're not writing extra junk into an mbuf; you're just starting
the mbuf's data a bit later.)





cgd