The MIT and ISC licenses are legally equivalent to the bsd2 license,
but with slightly different verbiage.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Michael Brown <mcb30@etherboot.org>

pxe_api.h is just a description of API functions, it's actively
undesirable to have more implementations than necessary.  Allowing it
under the MIT license lets the Syslinux libraries use it.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Michael Brown <mcb30@etherboot.org>

The commands bring in UNDI and thus real-mode code, so they cannot be
used on EFI.

Signed-off-by: Michael Brown <mcb30@etherboot.org>

Tested-by: Joshua Oreman <oremanj@xenon.get-linux.org>

In several places, we currently use size_t to represent a difference
between TCP sequence numbers.  This can cause compiler warnings
relating to printf format specifiers, since the result of
(uint32_t+size_t) may be an unsigned long on some compilers.

Fix by using uint32_t for all variables that represent a difference
between TCP sequence numbers.

Tested-by: Joshua Oreman <oremanj@xenon.get-linux.org>

The geniso, genliso and gensdsk scripts contain hard-coded temporary
directory names, and so could potentially collide with each other when
run as part of a concurrent build (e.g. "make -j 4").

Fix by using mktemp to generate suitable temporary directory names.

We add a syslinux floppy disk type using parts of the genliso script.
This floppy image cat be dd'ed to a physical floppy or used in
instances where a virtual floppy with an mountable DOS filesystem is
useful.

We also modify the genliso script to only generate .liso images
rather than creating images depending on how it is called.

Signed-off-by: Michael Brown <mcb30@etherboot.org>

This is required for all modern 802.11 devices, and allows drivers
to be written for them with minimally more effort than is required
for a wired NIC.

Signed-off-by: Michael Brown <mcb30@etherboot.org>
Modified-by: Michael Brown <mcb30@etherboot.org>

The Linux IB Communication Manager will always send MADs to QP1,
rather than back to the originating QP.  On Hermon, QP1 is by default
handled by the embedded firmware.  We can change this, but the cost is
that we have to handle both QP0 and QP1 (i.e. we have to provide SMA
as well as GMA service in software), and we have to use MLX queues
rather than standard UD queues (i.e. we have to construct the UD
datagrams by hand).

There doesn't seem to be any viable way around this situation, ugly
though it is.

The Communication Manager is responsible for handling the setup and
teardown of RC connections.

Queue pairs are now assumed to be created in the INIT state, with a
call to ib_modify_qp() required to bring the queue pair to the RTS
state.

ib_modify_qp() no longer takes a modification list; callers should
modify the relevant queue pair parameters (e.g. qkey) directly and
then call ib_modify_qp() to synchronise the changes to the hardware.

The packet sequence number is now a property of the queue pair, rather
than of the device.

Each queue pair may have an associated address vector.  For RC queue
pairs, this is the address vector that will be programmed in to the
hardware as the remote address.  For UD queue pairs, it will be used
as the default address vector if none is supplied to ib_post_send().

Now that MAD handlers no longer return a status code, we can allow
them to return a pointer to a MAD structure if and only if they want
to send a response.  This provides a more natural and flexible
approach than using a "response method" field within the handler's
descriptor.

MAD handlers have to set the status fields within the MAD itself
anyway, in order to provide a meaningful response MAD; the additional
gPXE return status code is just noise.

Note that we probably don't need to ever explicitly set the status to
IB_MGMT_STATUS_OK, since it should already have this value from the
request.  (By not explicitly setting the status in this way, we can
safely have ib_sma_set_xxx() call ib_sma_get_xxx() in order to
generate the GetResponse MAD without worrying that ib_sma_get_xxx()
will clear any error status set by ib_sma_set_xxx().)

Most IB hardware seems not to allow allocation of the genuine QPNs 0
and 1, so allow for the externally-visible QPN (as constructed and
parsed by ib_packet, where used) to differ from the real
hardware-allocated QPN.

The send completion handler typically will just free the I/O buffer,
so allow this common case to be handled by the Infiniband core.

Attempting the broadcast group join while the link is down is
harmless, but can generate annoying volumes of debug messages.

The GMA code was based upon the SMA code.  We can save space by making
the SMA simply an instance of the GMA.

Now that IPoIB has to deal with only one set of queues, the queue set
abstraction becomes merely an inconvenient wrapper.

All packets handled by the metadata queue set now go via the GMA.

Generalise out the multicast group membership record code from IPoIB.

The queue key is stored as a property of the queue pair, and so can
optionally be added by the Infiniband core at the time of calling
ib_post_send(), rather than always having to be specified by the
caller.

This allows IPoIB to avoid explicitly keeping track of the data queue
key.

Now that path record lookups are handled entirely via
ib_resolve_path(), the only role of the IPoIB peer cache is as a
lookup table for MAC addresses.  Update the code structure and
comments to reflect this.

The IPoIB broadcast MAC address varies according to the partition key.
Now that the broadcast MAC address is a property of the network device
rather than of the link layer, we can expose this real MAC address
directly.

The broadcast LID is now identified via a path record lookup; this is
marginally inefficient (since it was present in the MCMemberRecord
GetResponse), but avoids the need to special-case broadcasts when
constructing the address vector in ipoib_transmit().

Remove the special handling of the IPoIB broadcast QPN.

Generalise out the path record lookup code from IPoIB.

Generalise the subnet management agent into a general management agent
capable of sending and responding to MADs, including support for
retransmissions as necessary.

Currently, all Infiniband users must create a process for polling
their completion queues (or rely on a regular hook such as
netdev_poll() in ipoib.c).

Move instead to a model whereby the Infiniband core maintains a single
process calling ib_poll_eq(), and polling the event queue triggers
polls of the applicable completion queues.  (At present, the
Infiniband core simply polls all of the device's completion queues.)
Polling a completion queue will now implicitly refill all attached
receive work queues; this is analogous to the way that netdev_poll()
implicitly refills the RX ring.

Infiniband users no longer need to create a process just to poll their
completion queues and refill their receive rings.

IPoIB and the SMA have separate constants for the packet size to be
used to I/O buffer allocations.  Merge these into the single
IB_MAX_PAYLOAD_SIZE constant.

(Various other points in the Infiniband stack have hard-coded
assumptions of a 2048-byte payload; we don't currently support
variable MTUs.)

IPoIB has a link-layer broadcast address that varies according to the
partition key.  We currently go through several contortions to pretend
that the link-layer address is a fixed constant; by making the
broadcast address a property of the network device rather than the
link-layer protocol it will be possible to simplify IPoIB's broadcast
handling.

Move the icky call to step() from aoe.c to ata.c; this takes it at
least one step further away from where it really doesn't belong.

Unfortunately, AoE has the ugly aoe_discover() mechanism which means
that we still have a step() loop in aoe.c for now; this needs to be
replaced at some future point.

Move the icky call to step() from iscsi.c to scsi.c; this takes it at
least one step further away from where it really doesn't belong.

Reading sixteen columns of hex digits can be difficult; include a "-"
character to split the output into two groups of eight columns.

Objects typically call xfer_close() as part of their response to a
close() message.  If the initiating object has already nullified the
xfer interface then this isn't a problem, but it can lead to
unexpected behaviour when the initiating object is aiming to reuse the
connection and so does not nullify the interface.

Fix by always temporarily nullifying the interface during xfer_close()
(as was already being done by xfer_vreopen() in order to work around
this specific problem).

Reported-by: infernix <infernix@infernix.net>
Tested-by: infernix <infernix@infernix.net>