Subject: Implementation of RFC 1201 arcnet
To: None <Chris_G_Demetriou@LAGAVULIN.PDL.CS.CMU.EDU>
From: Ignatios Souvatzis <email@example.com>
Date: 03/16/1995 16:58:05
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 $ */
* 14.07.1994 TR -- Now shouldn't cause those NFS 'odd length' messages.
/* This should solve the NFS odd length packet problem... */
head->m_data += (((sizeof(struct ether_header) + 3) & ~3) -
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.