<feed xmlns='http://www.w3.org/2005/Atom'>
<title>openslx-ng/ipxe.git/src/net, branch v0.9.6</title>
<subtitle>Fork of ipxe; additional commands and features</subtitle>
<id>https://git.openslx.org/openslx-ng/ipxe.git/atom/src/net?h=v0.9.6</id>
<link rel='self' href='https://git.openslx.org/openslx-ng/ipxe.git/atom/src/net?h=v0.9.6'/>
<link rel='alternate' type='text/html' href='https://git.openslx.org/openslx-ng/ipxe.git/'/>
<updated>2008-11-21T20:34:02+00:00</updated>
<entry>
<title>[netdevice] Provide function to retrieve the most recently opened net device</title>
<updated>2008-11-21T20:34:02+00:00</updated>
<author>
<name>Michael Brown</name>
</author>
<published>2008-11-21T20:31:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.openslx.org/openslx-ng/ipxe.git/commit/?id=02a021587336a9ada3845025610ba836b173464d'/>
<id>urn:sha1:02a021587336a9ada3845025610ba836b173464d</id>
<content type='text'>
There are currently four places within the codebase that use a
heuristic to guess the "boot network device", with varying degrees of
success.  Add a feature to the net device core to maintain a list of
open network devices, in order of opening, and provide a function
last_opened_netdev() to retrieve the most recently opened net device.
This should do a better job than the current assortment of
guess_boot_netdev() functions.
</content>
</entry>
<entry>
<title>[aoe] Use an AoE config query to identify the target MAC address</title>
<updated>2008-11-19T21:42:33+00:00</updated>
<author>
<name>Michael Brown</name>
</author>
<published>2008-11-19T21:42:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.openslx.org/openslx-ng/ipxe.git/commit/?id=246ddf5ee4fe0d95f056ad00c670a4a851097418'/>
<id>urn:sha1:246ddf5ee4fe0d95f056ad00c670a4a851097418</id>
<content type='text'>
The AoE spec does not specify that the source MAC address of a
received packet actually matches the MAC address of the AoE target.
In principle an AoE server can respond to an AoE request on any
interface available to it, which may not be an address configured to
accept AoE requests.

This issue is resolved by implementing AoE device discovery.  The
purpose of AoE discovery is to find out which addresses an AoE target
can use for requests.  An AoE configuration command is sent when the
AoE attach is attempted.  The AoE target must respond to that
configuration query from an interface that can accept requests.

Based on a patch from Ryan Thomas &lt;ryan@coraid.com&gt;
</content>
</entry>
<entry>
<title>[x86_64] Fix assorted 64-bit compilation errors and warnings</title>
<updated>2008-11-19T19:33:05+00:00</updated>
<author>
<name>Michael Brown</name>
</author>
<published>2008-11-19T19:33:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.openslx.org/openslx-ng/ipxe.git/commit/?id=0ebbbb95fa03622423154a3e56251dd58832654d'/>
<id>urn:sha1:0ebbbb95fa03622423154a3e56251dd58832654d</id>
<content type='text'>
Remove various 32-bit assumptions scattered throughout the codebase.
The code is still not necessarily 64-bit clean, but will at least
compile.
</content>
</entry>
<entry>
<title>[i386] Change [u]int32_t to [unsigned] int, rather than [unsigned] long</title>
<updated>2008-11-19T19:15:44+00:00</updated>
<author>
<name>Michael Brown</name>
</author>
<published>2008-11-19T02:22:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.openslx.org/openslx-ng/ipxe.git/commit/?id=b59e0cc56eb6d5f3b6f934722931f6919309ffd2'/>
<id>urn:sha1:b59e0cc56eb6d5f3b6f934722931f6919309ffd2</id>
<content type='text'>
This brings us in to line with Linux definitions, and also simplifies
adding x86_64 support since both platforms have 2-byte shorts, 4-byte
ints and 8-byte long longs.
</content>
</entry>
<entry>
<title>[build] Keep gcc 4.4 happy</title>
<updated>2008-11-18T01:52:40+00:00</updated>
<author>
<name>Michael Brown</name>
</author>
<published>2008-11-18T01:52:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.openslx.org/openslx-ng/ipxe.git/commit/?id=54fbd11221e69eb2c840517b1fb7c1613930f899'/>
<id>urn:sha1:54fbd11221e69eb2c840517b1fb7c1613930f899</id>
<content type='text'>
gcc 4.4 adds another few warnings, and also seems to complain if we
place %ebp in the clobber list for any inline asm.
</content>
</entry>
<entry>
<title>[infiniband] Add raw packet parser and constructor</title>
<updated>2008-11-11T05:31:19+00:00</updated>
<author>
<name>Michael Brown</name>
</author>
<published>2008-11-07T08:39:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.openslx.org/openslx-ng/ipxe.git/commit/?id=9e5fd8ec59cd44dc9ba349d4feee37830fca6a14'/>
<id>urn:sha1:9e5fd8ec59cd44dc9ba349d4feee37830fca6a14</id>
<content type='text'>
This can be used with cards that require the driver to construct and
parse packet headers manually.  Headers are optionally handled
out-of-line from the packet payload, since some such cards will split
received headers into a separate ring buffer.
</content>
</entry>
<entry>
<title>[infiniband] Split subnet management agent client out into ib_smc.c</title>
<updated>2008-11-11T05:31:07+00:00</updated>
<author>
<name>Michael Brown</name>
</author>
<published>2008-11-06T22:31:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.openslx.org/openslx-ng/ipxe.git/commit/?id=663904a7bc4ced3b80d87df125b0e7cf90c1bfc2'/>
<id>urn:sha1:663904a7bc4ced3b80d87df125b0e7cf90c1bfc2</id>
<content type='text'>
Not all Infiniband cards have embedded subnet management agents.
Split out the code that communicates with such an embedded SMA into a
separate ib_smc.c file, and have drivers call ib_smc_update()
explicitly when they suspect that the answers given by the embedded
SMA may have changed.
</content>
</entry>
<entry>
<title>[infiniband] Pass address vector in receive completions</title>
<updated>2008-11-11T05:31:07+00:00</updated>
<author>
<name>Michael Brown</name>
</author>
<published>2008-11-06T21:20:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.openslx.org/openslx-ng/ipxe.git/commit/?id=830e19eb54f4ee2e6629612a3f296fbdba18e531'/>
<id>urn:sha1:830e19eb54f4ee2e6629612a3f296fbdba18e531</id>
<content type='text'>
Receive completion handlers now get passed an address vector
containing the information extracted from the packet headers
(including the GRH, if present), and only the payload remains in the
I/O buffer.

This breaks the symmetry between transmit and receive completions, so
remove the ib_completer_t type and use an ib_completion_queue_operations
structure instead.

Rename the "destination QPN" and "destination LID" fields in struct
ib_address_vector to reflect its new dual usage.

Since the ib_completion structure now contains only an IB status code,
("syndrome") replace it with a generic gPXE integer status code.
</content>
</entry>
<entry>
<title>[infiniband] Maintain queue fill level as a property of a work queue</title>
<updated>2008-11-11T05:31:06+00:00</updated>
<author>
<name>Michael Brown</name>
</author>
<published>2008-10-03T02:04:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.openslx.org/openslx-ng/ipxe.git/commit/?id=0de5f7af6db39ea9173caa0015a63353174d72ce'/>
<id>urn:sha1:0de5f7af6db39ea9173caa0015a63353174d72ce</id>
<content type='text'>
Both queue owners and drivers often need to keep track of the fill
level, so let's make it a generic property.
</content>
</entry>
<entry>
<title>[infiniband] Flush uncompleted work queue entries at QP teardown</title>
<updated>2008-11-11T05:31:06+00:00</updated>
<author>
<name>Michael Brown</name>
</author>
<published>2008-10-02T23:07:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.openslx.org/openslx-ng/ipxe.git/commit/?id=d9751edafa08b2ec3779004d4209400b95884cd4'/>
<id>urn:sha1:d9751edafa08b2ec3779004d4209400b95884cd4</id>
<content type='text'>
Avoid leaking I/O buffers in ib_destroy_qp() by completing any
outstanding work queue entries with a generic error code.  This
requires the completion handlers to be available to ib_destroy_qp(),
which is done by making them static configuration parameters of the CQ
(set by ib_create_cq()) rather than being provided on each call to
ib_poll_cq().

This mimics the functionality of netdev_{tx,rx}_flush().  The netdev
flush functions would previously have been catching any I/O buffers
leaked by the IPoIB data queue (though not by the IPoIB metadata
queue).
</content>
</entry>
</feed>
