Differences
This shows you the differences between two versions of the page.
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 |