I'm back! Trip was a lot of fun, but I'm glad to be back working on gPXE.
I spent a bit of time today getting my code up to date with the changes that have been made on gPXE mainline while I was away. The effect of this is a new mainline-review branch with its three core pending wireless commits slightly modified, and a merge commit on the wireless branch.
I also started working on the device firmware loading we discussed in my last weekly meeting before I left. The problem is not at all complicated and I expect to have it done by early tomorrow.
Firmware loading is done and tested with a trivial application. (I don't own any cards supported by gPXE that actually require firmware.)
A device needing firmware declares that dependency using a REQUIRE_FIRMWARE() or USE_FIRMWARE() macro, where REQUIRE is meant to have the semantics that a link without the firmware file available will fail. Depending on the architecture this may not always be the case (it simply uses the underlying REQUIRE_OBJECT() macro defined in compiler.h). It gets at the firmware data using a function request_firmware().
I have modified the build system so that any file in the src/firmware/ directory whose name does not start with README will automatically be compiled in as an embedded image if another compiled-image object uses REQUIRE_FIRMWARE() or USE_FIRMWARE() to pull it in.
Currently USE_FIRMWARE() is implemented rather uglily, by adding a Perl script that searches for USE_FIRMWARE() uses and creates a linker script to provide dummy symbols preventing a link error only if the used firmware is not available at link-time. I have found in my testing that REQUIRE_FIRMWARE() does not actually introduce a strong dependency, so that on x86 at least the two are equivalent and there is no need for the Perl script ugliness. I am not sure whether this is a portable assumption, but since REQUIRE_OBJECT() works by producing a symbol reference without ever using the symbol value, it may be. If so the situation can be rather simplified—take out REQUIRE_FIRMWARE() entirely, and the fwfix.pl Perl script as well.
The ath5k driver is rather slow going, because there's just so very much of it (about 10x as much code as rtl818x). As this is the first driver I've worked with that supports 802.11a devices, the first stage of the port revealed some issues with net80211's handling of multiple bands (some oversimplifying assumptions I had made); I think these have been fixed, though I need to update rtl818x to fit with the API changes they involved.
I will be away Friday through Monday, and back Tuesday the 28th—see you then!