This will allow us to implement RX quotas.

to the PIC while it was disabled.

manage to return control.

real_call(), rather than moving it to the RM stack and back again.
This allows the real-mode function to completely destroy the stack
contents, provided that it manages to return to real_call().

  "when SYN is ACKed and we have already received SYN", or
  "when SYN is received and we have already had SYN ACKed"

rather than just

  "when SYN is ACKed"

This avoids spuriously calling the connected() method when we receive
a RST,ACK in response to a SYN.

it's a serial console and remembers state from the previous program
run.

may be called during the RX data processor, before the RX engine
transitions back to idle.  It doesn't really matter if the RX engine
isn't idle when iscsi_done() is called, because it will just pick up
where it left off on the next call.  (The same is not true for the TX
engine, so keep the TX engine assertion.)

UNDI ROM code etc. when you just want a "undi.kpxe"-type image).

This driver cannot be used in conjunction with any other driver (it will
crash), or in any other format than .kpxe (it just won't find any network
devices).

it directly to undi_load_pci().

addresses if the signature checks fail.

we can never return to the PXE stack and must always use INT 18.

loader.

UNDI stack.

Record all information required for populating a struct undi_device.

Make debugging output more human-readable.

able to populate the structure.

and call UNDI_SHUTDOWN first to make sure the NIC is in a safe state.

memory (unless we get an error while stopping the base code).  Leave UNDI
resident (though stopped) for .kpxe.

Still need to add code to record the device identification parameters
prior to stopping UNDI.

undi_rom rather than struct pxe_driver.  (This is part of the naming
consistency fixes).

function prefix "undinet_" and the variable name "undinic" in undinet.c,
so that we can reserve the variable name "undi" for a struct undi_device.

The idea is that we preserve the Etherboot 5.4 convention that the "UNDI"
code refers to our using an underlying UNDI stack, while the "PXE" code
refers to our providing a PXE API.

way everything remains consistent if the probe() ends up creating child
devices.

UNDI_GET_INFORMATION calls into drivers/net/undi.c.  undi_probe() now
gets given a pxe_device representing a PXE stack that has been loaded
into memory but not initialised in any way.

Handle failures in undi_open() properly.