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.

Guess its taken from Amiga (based on hp300) if_le.c or i386 if_ed.c,
which where the base of Amiga if_ed.c.

Exact code I refer to, from 
/*	$NetBSD: if_ed.c,v 1.6 1995/02/12 19:19:11 chopps Exp $	*/

is: 
(line 44:)
 * 14.07.1994 TR -- Now shouldn't cause those NFS 'odd length' messages.

(line 547:)
	/* This should solve the NFS odd length packet problem... */
	head->m_data += (((sizeof(struct ether_header) + 3) & ~3) -
	    sizeof(struct ether_header));


		***


   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.

You're saying, a subroutine call is cheaper than a 256 byte array
indexing? Or is it simply a matter of programming style?

Btw, I'd rather default to 1 or 2 bytes (2 being for the newer style
of arc header).

   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.)

Yes, of course. I never thougt about anything else.

Regards,
	Ignatios Souvatzis