The more natural way for beacons to flow from the 80211.o to the low level driver would be for beacons to be passed down just like any other 802.11 frame is passed down - rather than having a special case for beacons and buffered MC data, where they are pulled. I would suggest making the qdisc aware of beacons, and then there is no special interface for passing beacons down - they are passed down just like other frames, with a special queue ID reserved for beacons and buffered multicast.
This would simplify the 80211.o/low level interface. Simon -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jouni Malinen Sent: Wednesday, March 15, 2006 4:36 PM To: Jiri Benc Cc: netdev@vger.kernel.org Subject: Re: [RFC/PATCH 6/13] d80211: remove obsolete stuff On Mon, Mar 06, 2006 at 04:44:26PM +0100, Jiri Benc wrote: > Because any number of interfaces may be added, bss_devs and sta_devs > arrays cannot be fixed-size arrays. We can make them linked lists, but > they are needed for optimalization only (and even that is questionable > with subsequent patches). Let's remove them; we will probably want > something similar later to speed up packet receiving, but let's not > bother ourselves now. > @@ -277,9 +277,6 @@ struct ieee80211_conf { > int antenna_def; > int antenna_mode; > > - u8 bssid_mask[ETH_ALEN]; /* ff:ff:ff:ff:ff:ff = 1 BSSID */ > - int bss_count; In theory, the low-level driver can determine the needed mask itself. However, it would need to be somehow notified of allowed BSSID values. By removing this entry, this information would need to fetched from somewhere else before interfaces are added. Most hardware implementations have storage for a single MAC address in EEPROM (or something similar) and in some cases, no addresses are stored with the card and some external store is needed for this. We have been using this mechanism of passing the information from user space to avoid problems in figuring out board specific mechanisms for storing extra data. Do you have any ideas on what would be the best of getting this information configured after this change? > --- dscape.orig/net/d80211/ieee80211.c 2006-03-06 14:10:18.000000000 +0100 > +++ dscape/net/d80211/ieee80211.c 2006-03-06 14:10:22.000000000 +0100 > @@ -1569,17 +1569,14 @@ struct sk_buff * ieee80211_beacon_get(st > u8 *b_head, *b_tail; > int bh_len, bt_len; > > - spin_lock_bh(&local->sub_if_lock); > - if (bss_idx < 0 || bss_idx >= local->bss_dev_count) > - bdev = NULL; > - else { > - bdev = local->bss_devs[bss_idx]; > + bdev = dev_get_by_index(bss_idx); This and similar change for ieee80211_get_buffered_bc() add more requirements for the low-level driver. It used to be enough to just know that the low-level code should ask for up to N beacon frames. However, with this change, the low-level driver would need to maintain a list of ifindexes for the virtual interfaces. This is somewhat against the original design of hiding all the virtual interfaces from low-level code. I think the ifindex values could be made available from add/remove interface calls that you added. Was that what you had in mind or is there another mechanism for getting the needed ifindexes down? I need to understand this bit better in order to be able to modify the low-level driver to handle this kind of change. At the moment, this change does not look very good to me because of the extra requirement added for the low-level code as far as virtual interfaces are concerned. -- Jouni Malinen PGP id EFC895FA - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
