Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Last revision Both sides next revision
soc:2009:oremanj:journal:week5 [2009/06/26 21:45]
rwcr
soc:2009:oremanj:journal:week5 [2009/06/26 21:54]
rwcr
Line 113: Line 113:
  
 The issue I noted in the last paragraph of yesterday'​s entry was not quite so bad as it seemed; after accounting for different header bytes and different version numbers, for gPXE's purposes the bulk of the WPA and RSN information elements can be parsed identically. Huzzah. The two versions still have some respective idiosyncracies in the handling of the 4-Way Handshake (which is next up on the list of things to write), but the ''​wpa_supplicant''​ code is a good reference for that. The issue I noted in the last paragraph of yesterday'​s entry was not quite so bad as it seemed; after accounting for different header bytes and different version numbers, for gPXE's purposes the bulk of the WPA and RSN information elements can be parsed identically. Huzzah. The two versions still have some respective idiosyncracies in the handling of the 4-Way Handshake (which is next up on the list of things to write), but the ''​wpa_supplicant''​ code is a good reference for that.
 +
 +I now offer an interlude of Cool Linker Tricks.
  
 One of the things I did today was move all the helper functions that will only be needed when some encryption method is supported into a separate file, ''​sec80211.c'',​ so they don't bloat the code size in wireless builds that don't use encryption. There'​s one chink in that: the main wireless probe code needs to be able to differentiate fully between the various types of secured network even if they'​re not all supported, as WPA looks like WEP to a client that knows nothing about WPA. So ''​net80211_probe_step()''​ has to call ''​sec80211_detect()'',​ but we don't want that call to pull in ''​sec80211.c''​ if nothing else needs it. One of the things I did today was move all the helper functions that will only be needed when some encryption method is supported into a separate file, ''​sec80211.c'',​ so they don't bloat the code size in wireless builds that don't use encryption. There'​s one chink in that: the main wireless probe code needs to be able to differentiate fully between the various types of secured network even if they'​re not all supported, as WPA looks like WEP to a client that knows nothing about WPA. So ''​net80211_probe_step()''​ has to call ''​sec80211_detect()'',​ but we don't want that call to pull in ''​sec80211.c''​ if nothing else needs it.
Line 135: Line 137:
 This is rather messy, of course; the fewer symbols with an implicit "​might-be-NULL"​ attached the better. But for fairly tightly-coupled source files that need to be separated for size reasons, one or two weak functions can provide an excellent interface between the two. This is rather messy, of course; the fewer symbols with an implicit "​might-be-NULL"​ attached the better. But for fairly tightly-coupled source files that need to be separated for size reasons, one or two weak functions can provide an excellent interface between the two.
  
-While we're in the Cool Linker Tricks department, there'​s also something called a "weak alias",​ which serves a completely different purpose: providing one implementation of an API function while allowing it to be superseded without complaint by another object file. I haven'​t seen anything in gPXE that really needs this, but to give an example of how it //could// be used, gPXE core defines a simple ''​memcpy()''​ function that doesn'​t know about any architecture-specific optimizations,​ but only declares its prototype if the preprocessor macro ''​__HAVE_ARCH_MEMCPY''​ hasn't been defined by architecture-specific includes; that allows architecture-specific string functions to be used instead, using either ''#​define''​ or an inline implementation,​ but no symbol can be named ''​memcpy''​ because the linker would complain. A way around that would be:+While we're in the Cool Linker Tricks department, there'​s also something called a "weak alias",​ which serves a completely different purpose: providing one implementation of an API function while allowing it to be superseded without complaint by another object file. I haven'​t seen anything in gPXE that really needs this, but to give an example of how it //could// be used, gPXE core defines a simple ''​memcpy()''​ function that doesn'​t know about any architecture-specific optimizations,​ but only declares its prototype if the preprocessor macro ''​%%__HAVE_ARCH_MEMCPY%%''​ hasn't been defined by architecture-specific includes; that allows architecture-specific string functions to be used instead, using either ''#​define''​ or an inline implementation,​ but no symbol can be named ''​memcpy''​ because the linker would complain. A way around that would be:
   /* in core string code */   /* in core string code */
   void * core_memcpy ( void *dest, const void *src, int len ) {   void * core_memcpy ( void *dest, const void *src, int len ) {
           /* ... */           /* ... */
   }   }
 +  ​
   void * memcpy ( void *dest, const void *src, int len )   void * memcpy ( void *dest, const void *src, int len )
           __attribute__ (( weak, alias ( "​core_memcpy " ) ));           __attribute__ (( weak, alias ( "​core_memcpy " ) ));
 Then architecture-specific code could just define ''​memcpy''​ directly, no preprocessor tricks needed, and it would supersede the core version. Again, I don't think anything needs this at this point, but it's cool to know - maybe it'll even come in handy someday! :-) Then architecture-specific code could just define ''​memcpy''​ directly, no preprocessor tricks needed, and it would supersede the core version. Again, I don't think anything needs this at this point, but it's cool to know - maybe it'll even come in handy someday! :-)

Navigation

* [[:start|Home]] * [[:about|About our Project]] * [[:download|Download]] * [[:screenshots|Screenshots]] * Documentation * [[:howtos|HowTo Guides]] * [[:appnotes|Application Notes]] * [[:faq:|FAQs]] * [[:doc|General Doc]] * [[:talks|Videos, Talks, and Papers]] * [[:hardwareissues|Hardware Issues]] * [[:mailinglists|Mailing lists]] * [[http://support.etherboot.org/|Bugtracker]] * [[:contributing|Contributing]] * [[:editing_permission|Wiki Edit Permission]] * [[:wiki:syntax|Wiki Syntax]] * [[:contact|Contact]] * [[:relatedlinks|Related Links]] * [[:commerciallinks|Commercial Links]] * [[:acknowledgements|Acknowledgements]] * [[:logos|Logo Art]]

QR Code
QR Code soc:2009:oremanj:journal:week5 (generated for current page)