Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
soc:2009:oremanj:journal:week9 [2009/07/22 12:28] rwcr |
soc:2009:oremanj:journal:week9 [2009/07/23 18:34] rwcr |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Joshua Oreman: 802.11 wireless development ====== | ====== Joshua Oreman: 802.11 wireless development ====== | ||
| - | ===== Journal Week 6 ===== | + | ===== Journal Week 9 ===== |
| ==== Tuesday, 21 July ==== | ==== Tuesday, 21 July ==== | ||
| Line 23: | Line 23: | ||
| 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. | 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. | ||
| + | ==== Thursday, 23 July ==== | ||
| + | * On new branch **ath5k**: | ||
| + | * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=a9ae7776e1bcfeeb6df1e83ecee6ac03666581cc| | ||
| + | [ath5k] Initial import of Linux ath5k driver source]] | ||
| + | * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=da1261339b6b51c5b5cce2dd0b484d4cd1476495| | ||
| + | [legal] Add MIT licence declaration]] | ||
| + | * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=2071563d80aa06c036b9958d50696ff45bfcd504| | ||
| + | [802.11] Allow better driver specification of supported rates and channels]] | ||
| + | * [[http://git.etherboot.org/?p=people/oremanj/gpxe.git;a=commit;h=78992f21dc5c728bb1de42442ca561ff4a3e4f33| | ||
| + | [ath5k] Start gPXEifying ath5k driver]] | ||
| + | |||
| + | 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! | ||
