====== Differences ====== This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision | |||
|
soc:2009:oremanj:notes:design [2009/06/22 14:53] rwcr |
soc:2009:oremanj:notes:design [2009/06/22 14:54] (current) rwcr |
||
|---|---|---|---|
| Line 4: | Line 4: | ||
| The below are my thoughts about a week into the coding season. They may change without warning. This is not meant to be a complete API guide; there are comments in the header files for that. **Update:** As of Week 5 these have been updated for accuracy, if not completeness. | The below are my thoughts about a week into the coding season. They may change without warning. This is not meant to be a complete API guide; there are comments in the header files for that. **Update:** As of Week 5 these have been updated for accuracy, if not completeness. | ||
| - | + | ||
| 802.11 drivers should "feel" like regular NIC drivers. They'll need to handle more things, because wireless networking is more complex than wired, but the programming interface should be similar. 802.11 has a lot of MAC-layer processing, though, so there needs to be a shim between the driver layer and the ll_protocol push/pull. I chose to implement this by creating a ''net80211_device'', and having the 802.11 MAC layer set up a normal ''net_device'' to wrap it. | 802.11 drivers should "feel" like regular NIC drivers. They'll need to handle more things, because wireless networking is more complex than wired, but the programming interface should be similar. 802.11 has a lot of MAC-layer processing, though, so there needs to be a shim between the driver layer and the ll_protocol push/pull. I chose to implement this by creating a ''net80211_device'', and having the 802.11 MAC layer set up a normal ''net_device'' to wrap it. | ||
