The e1000_irq() routine should (per mcb30) do enable on non-zero,
disable on zero.  This is not consistent in all drivers, so I'll
wait to update it when doing a global sweep.

This needs to be done manually because if the irq() routine is
implemented then we want something like "nic->irqno = pci->irqno;",
else we do "nic->irqno = 0;" nic->ioaddr may also need to be set
carefully.

Also added local variables to end of many files, for emacs indentation
to match kernel style (tab does 8 space indent).

for "echo -e" on the host system.

_textdata_link_addr, _load_addr and _max_align in the linker scripts.
A bug in some versions of ld causes segfaults if the DEFINED() macro
is used in a linker script *and* the -Map option to ld is present.

We don't currently need to override any of these values; if we need to
do so in future then the solution will probably be to always specify
the values on the ld command line, and have the linker script not
define them at all.

suitable "echo -e" substitute.

is non-functional anyway.

PXENV_GET_CACHED_INFO.  NTLDR does this.

Cleanups for e1000.c.

supply options.

PXENV_GET_CACHED_INFO.  If we dont do this, Altiris' NBP screws up; it
relies on being able to grab pointers to each of the three packets and
then read them at will later.

s_PXENV_GET_CACHED_INFO, because this field doesn't exist in earlier
versions of the PXE spec, and some callers don't allocate space for it.

also avoid waiting for ProxyDHCP offers).

Also reduce the ProxyDHCP timeout, because it's already irritating me.

I have successfully booted DOS via iSCSI and PXELINUX via TFTP with this
version of the e1000 driver.

implemented smbios_get_uuid().

potentially exorbitant amounts of stack space.

There may still be an issue with memory handling, since it seems to
die ungracefully when ARP packets come in after loading a kernel.
Something to debug.

autonegotiation still needs work.  receive is not working yet.

needing to know the gPXE internal ROM name.

It is likely we will rename e1000_main to e1000 when the new e1000 driver is debugged.

We didn't specify values for MaxRecvDataSegmentLength and
MaxBurstLength (to save space, since we were happy with the
RFC-defined default values of 8kB and 256kB respectively).  However,
the OpenSolaris target (incorrectly) assumes default values of zero
for these parameters.

The upshot was that the OpenSolaris target would get stuck in an
endless loop trying to send us the first 512-byte sector, zero bytes
at a time, and would eventually run out of memory and core-dump.

Fixed by explicitly specifying the default values for these two
parameters.

allowing any space for this, which makes it surprising that bzImage
loading ever worked.