Differences

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

Link to this comparison view

Next revision
Previous revision
wirelessboot:drivers [2009/08/11 20:03]
rwcr created
wirelessboot:drivers [2009/08/11 20:11] (current)
rwcr
Line 23: Line 23:
 large 802.11 stack; when the file introducing them can be compiled in large 802.11 stack; when the file introducing them can be compiled in
 or out due to a configuration option, the ''​REQUIRE_OBJECT()''​ calls or out due to a configuration option, the ''​REQUIRE_OBJECT()''​ calls
-should be placed in ''​net/​80211/​config_80211.c''​ instead of +should be placed in ''​config_net80211.c''​ instead of 
-''​core/config.c''​ to avoid ever pulling in the objects without a+''​config.c''​ to avoid ever pulling in the objects without a
 wireless stack present to make them useful. wireless stack present to make them useful.
  
Line 49: Line 49:
 pointer, while others have analogues in the ''​net80211_device''​ pointer, while others have analogues in the ''​net80211_device''​
 structure directly. Specifically:​ structure directly. Specifically:​
-  * For a wired NIC, the proper MAC address to use is always +  * For a wired NIC, the proper MAC address to use is always ''​netdev->​ll_addr''​. For a wireless NIC, there are two available: ''​dev->​netdev->​ll_addr''​ is the MAC address most recently configured by the user, and ''​dev->​hw->​hwaddr''​ is the MAC address burned into the card. Usually (e.g. for setting the RX filter) the former should be used. 
-    ​''​netdev->​ll_addr''​. For a wireless NIC, there are two available: +  * Any access to ''​netdev->​name''​ and ''​netdev->​ll_protocol''​ should continue to use the wrapping ''​net_device''​. 
-    ​''​dev->​netdev->​ll_addr''​ is the MAC address most recently +  * The ''​netdev->​state''​ field retains its validity, but for wireless it does not provide much status detail. The ''​netdev->​link_rc''​ field is useful for presenting a user-visible error, and it keeps its value until a different error or a success. For programmatic status information,​ ''​dev->​state''​ contains the most recent 802.11 status code and several bits indicating how network association is progressing. 
-    ​configured by the user, and ''​dev->​hw->​hwaddr''​ is the MAC address +  * The ''​netdev->​priv''​ now points to the wrapped ''​net80211_device''​ structure. Driver-private data must be accessed using ''​dev->​priv''​ (the ''​priv''​ field in the ''​net80211_device''​ itself).
-    ​burned into the card. Usually (e.g. for setting the RX filter) the +
-    ​former should be used. +
-  * Any access to ''​netdev->​name''​ and ''​netdev->​ll_protocol''​ should +
-    ​continue to use the wrapping ''​net_device''​. +
-  * The ''​netdev->​state''​ field retains its validity, but for wireless +
-    ​it does not provide much status detail. The ''​netdev->​link_rc''​ +
-    ​field is useful for presenting a user-visible error, and it keeps +
-    ​its value until a different error or a success. For programmatic +
-    ​status information,​ ''​dev->​state''​ contains the most recent 802.11 +
-    ​status code and several bits indicating how network association is +
-    ​progressing. +
-  * The ''​netdev->​priv''​ now points to the wrapped ''​net80211_device''​ +
-    ​structure. Driver-private data must be accessed using +
-    ​''​dev->​priv''​ (the ''​priv''​ field in the ''​net80211_device''​ itself).+
  
-There are also //many// more fields in ''​net80211_device''​ than in +There are also //many// more fields in ''​net80211_device''​ than in ''​net_device'',​ owing to the significant added complexity of wireless. Those that a driver writer needs to know about are: 
-''​net_device'',​ owing to the significant added complexity of +  * ''​dev->​hw''​ contains a pointer to the ''​net80211_hw_info''​ structure passed to ''​net80211_register()''​. 
-wireless. Those that a driver writer needs to know about are: +  * ''​dev->​channels''​ is a list of 802.11 channels that might be used, each identified by a structure indicating center frequency, standard channel number, transmission power, etc. ''​dev->​nr_channels''​ contains a count of channels, and ''​dev->​channel''​ is the index of the channel currently in use. 
-  * ''​dev->​hw''​ contains a pointer to the ''​net80211_hw_info''​ +  * In the same vein, ''​dev->​rates''​ is an array of transmission rates counted by ''​dev->​nr_rates''​ and indexed by ''​dev->​rate''​. For simplicity, rates are not represented using a structure, but instead simply as an integral multiple of 100,000 bits per second. 
-    ​structure passed to ''​net80211_register()''​. +  * ''​dev->​rtscts_rate''​ is the index of the rate that should be used for RTS and CTS (request-to-send and clear-to-send) frames, if their use is necessary. 
-  * ''​dev->​channels''​ is a list of 802.11 channels that might be used, +  * ''​dev->​bssid''​ is the MAC address of the Access Point with which the card is associated; generally this is used in setting the RX filter. 
-    ​each identified by a structure indicating center frequency, +  * ''​dev->​phy_flags''​ is a bitmask of physical-layer flags (whether or not to use short preamble, short slot time, or CTS protection) that the driver must communicate appropriately to the card.
-    ​standard channel number, transmission power, etc. +
-    ​''​dev->​nr_channels''​ contains a count of channels, and +
-    ​''​dev->​channel''​ is the index of the channel currently in use. +
-  * In the same vein, ''​dev->​rates''​ is an array of transmission rates +
-    ​counted by ''​dev->​nr_rates''​ and indexed by ''​dev->​rate''​. For +
-    ​simplicity, rates are not represented using a structure, but +
-    ​instead simply as an integral multiple of 100,000 bits per second. +
-  * ''​dev->​rtscts_rate''​ is the index of the rate that should be used +
-    ​for RTS and CTS (request-to-send and clear-to-send) frames, if +
-    ​their use is necessary. +
-  * ''​dev->​bssid''​ is the MAC address of the Access Point with which +
-    ​the card is associated; generally this is used in setting the RX +
-    ​filter. +
-  * ''​dev->​phy_flags''​ is a bitmask of physical-layer flags (whether +
-    ​or not to use short preamble, short slot time, or CTS protection) +
-    ​that the driver must communicate appropriately to the card.+
  
 To manage these additional wireless-specific issues, a new API To manage these additional wireless-specific issues, a new API

QR Code
QR Code wirelessboot:drivers (generated for current page)