> Gcc2 generates memcpy calls when doing some structure copying in the

>  Gcc2 generates memcpy calls when doing some structure copying in the
> code. As this memcpy generation is done by the compiler it doesn't
> work to have memcpy a macro. Instead I made it a static function that
> calls bcopy.

Okay, I tracked down the d*mn thing that is causing the memcpy to be
emmitted by gcc2.  In the following patch is a fix to eliminate the
one place that was causing gcc to do the memcpy in function ie_readframe
for the ie_recv_frame_desc rfd = *(ie->rframes[num]) structure copy.

I also fixed the code so that the NS (XNS) support would compile with
out error and removed the cruft #define ns_* stuff from the softc
structures (I did this a while back for all the other either drivers)

Removed the $Log$ and all of the old log stuff, that is all kept in
the cvs tree, no need to duplicate it in the file... I'll copy it
into my commit message so that it is all retained, except the
revision numbers are going to get screwed up.

It now compiles cleanly under my LINT kernel...

>  I have not yet tested this on the AT&T fiver cards yet. But, Wollman
> has used it on various other AT&T cards. I'm pretty sure Terry also
> uses this driver.

$Log$ stuff from Garretts original file
 * $Log$
 * Revision 1.32  1993/06/20  15:56:15  wollman
 * Fixed warning message.
 *
 * Revision 1.31  93/06/20  15:52:28  wollman
 * More compilation lint.
 *
 * Revision 1.30  93/06/20  15:48:16  wollman
 * Commented all the rest of the cast-qual warnings.  Might be
 * fixed someday by changing the prototypes of bcopy(), bzero(), etc.
 *
 * Revision 1.29  93/06/20  15:40:13  wollman
 * Started fixing some of the cast-qual warnings (most just commented).
 *
 * Revision 1.28  93/06/12  20:39:14  wollman
 * Changed definition of MK_24 to silence -Wcast-qual.
 *
 * Revision 1.27  93/06/08  17:05:57  wollman
 * Attach routine now returns void.
 *
 * Revision 1.26  93/06/08  16:31:21  wollman
 * Deleted attempt to set watchdog timer, since we don't use it.
 *
 * Revision 1.25  93/04/16  22:15:31  wollman
 * Fixed infinite loop in iestart() which would cause the transmitter
 * to constantly step on the Ethernet, sending the same two packets over
 * and over again.  This crashes the router (really!) and makes other
 * network users very angry.
 *
 * Revision 1.24  93/04/14  23:57:47  wollman
 * Increased transmit buffer size from 1504 to 1512, just in case I don't
 * understand how the MTU is used.
 *
 * Revision 1.23  93/04/14  23:16:19  wollman
 * Fix iestart() so that it only tries to execute a command if one was
 * queued up (oops...).
 *
 * Revision 1.22  93/04/14  23:02:16  wollman
 * Unknown changes.
 *
 * Revision 1.21  93/04/12  18:29:33  wollman
 * Added multiple transmit commands.  Note that they are always queued in
 * pairs (there are only two to begin with), and the I flag is only set
 * on the second one.  This should decrease interrupt activity somewhat.
 *
 * Revision 1.20  93/04/12  15:36:05  wollman
 * Changed setup of config block to take into account difference between
 * StarLAN (10BASE-T) and Ethernet: StarLAN is Manchester, Ethernet is NRZ.
 *
 * Revision 1.19  93/03/23  18:58:44  wollman
 * Raised count of receive buffers from 32 to 48 and included analysis of
 * memory usage in a comment near that definition.
 *
 * Revision 1.18  93/03/18  03:59:53  wollman
 * Last try to get large TCP windows to work...
 *
 * Revision 1.17  93/03/18  03:54:10  wollman
 * Added RNR processing as a part of receive interrupts.  Hopefully this
 * will make everything Just Work now.
 *
 * Revision 1.16  93/03/18  03:23:24  wollman
 * Still having problems with RNR conditions.  Basic problem: say we
 * set TCP window to 16k, which is a semsible value.  Then smart
 * partners will blast 16k to us, of which we can fit 8k minus a bit
 * into our buffers.  (Need to look at that memory map..)  So, we get
 * an RNR interrupt.  The problem is, what do we need to do in this case?
 * The original code doesn't work, but it doesn't hang the system either.
 *
 * Revision 1.15  93/03/18  02:37:00  wollman
 * Disabled watchdog timer.  This gets called from a timeout somewhere,
 * which is running up at softclock.  This is at a higher priority than
 * we are, so we can get interrupted in the process of receiving something
 * by the timer expiration, which is not a nice thing to have happen.
 * Question: how can we keep this functionality, but do it in sync with
 * our interrupts?  (Ugh!)
 *
 * Revision 1.14  93/03/18  02:35:46  wollman
 * Fixed some more problems with receive code---it works!
 *
 * Revision 1.13  93/03/17  20:15:59  wollman
 * Think we fixed the serious (showstopper) bugs in 1.12.
 *
 * Revision 1.12  93/03/15  17:45:39  wollman
 * Changed filtering logic dramatically to avoid the unnecessary copyin
 * for BPF or multicast routing when the packet is not for us.  (We
 * have to run in promiscuous mode in this case.)  We still need to
 * deal with the problem of allocating one mbuf per receive buffer;
 * we should be able to get away with a single mbuf for all reasonable
 * incoming packets, and using an mbuf cluster will help avoid unnecessary
 * copying of data.
 *
 * Revision 1.11  93/01/30  20:23:15  wollman
 * Fiddled with reset code to hopefully make it work better when the
 * watchdog timer expires.  Question: why does it make a difference that
 * we do the same thing through ieioctl() as we were doing before.  The
 * old code, when iereset() was called, the receive unit would completely
 * die.  But, a cycle of ifconfig ie0 down ; ifconfig ie0 up' would bring
 * things back to normal.  So, we try to mimic that now.  Grrr...
 *
 * Revision 1.10  93/01/29  17:26:50  wollman
 * Finally fixed multicast routing/BPF mb_map full problem!!!!
 * It turned out that, when we received a packet not for us, we
 * would just return from ie_readframe(), *WITHOUT* freeing the
 * mbuf that the packet was in.  So, when running in promiscuous
 * mode (i.e., multicast routing or BPF without -p), we would have
 * (on our extremely busy subnet 4) a memory leak of epic proportions.
 *
 * We now hold on to a single mbuf chain allocated in this way,
 * and the next time a packet is read, we free it.  Also, the
 * next time a packet is transmitted, we free it.  This way,
 * we never lose more than 6 mbufs total (and on average more like
 * 3).
 *
 * Revision 1.9  93/01/23  14:22:21  wollman
 * Added some StarLAN Fiber modifications from L. Jonas Olsson.
 *
 * Revision 1.8  93/01/23  14:02:34  wollman
 * Added support for IP multicasting.
 *
 * Revision 1.7  92/11/21  17:51:59  wollman
 * Added StarLAN Fiber version point to my driver.
 *
 * Revision 1.6  92/11/20  18:21:45  wollman
 * Fixed documentation, made out-of-mbuf condition an error.
 *
 * Revision 1.5  92/11/20  18:14:02  wollman
 * Move change of ethertype to host byte order so that it's after
 * bpf_mtap.  Hopefully, this will allow us to listen to incoming
 * IP packets.
 *
 * Revision 1.4  92/11/20  18:11:00  wollman
 * Added code to drop packets when we run out of mbufs rather than
 * panicking.  This should alleviate the problems observed when using tcpdump.
 *
 * Revision 1.3  92/11/14  14:12:40  wollman
 * Added BPF support code.
 *
 * Revision 1.2  92/11/14  13:30:26  wollman
 * Added RCS keywords
 *