On Fri, Jul 15, 2011 at 2:00 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Fri, 2011-07-15 at 12:30 -0700, Thomas Pedersen wrote: > >> >> + if (ieee80211_vif_is_mesh(&sdata->vif)) >> >> + rcu_assign_pointer(sdata->u.mesh.beacon, new); > >> The ifdef is already in ieee80211_vif_is_mesh() > > Yeah but sdata->u.mesh doesn't exist without mesh configured. > >> > what's + 400? You can't really think the TIM IE is that long? >> >> No, but you're right, that number is pretty arbitrary. Maximum length >> of mesh IEs currently (Mesh ID + Mesh Conf + Mesh Awake) is only 47. >> Since mesh IEs have to be added during beacon time, might it make >> sense to track the needed length in the if_mesh? > > Maybe just add a comment what's included in the 400? > >> > Also ... since you'll need PS support eventually anyway, maybe you >> > should refactor "struct ieee80211_if_ap" into something AP-specific >> > (currently only VLANs) and the rest, and then use "the rest" in mesh as >> > well to make all this code more unified. >> >> I like this approach much better. Are you suggesting just factoring >> out the PS data, or taking it further and creating a generic "if which >> beacons"? > > Well, I don't think "iface which beacons" is really what we need here -- > IBSS sends beacons as well but we don't really have PS support there and > it'd be different anyway. But on the other hand, if you also factor out > the beacon pointer, you can embed that into both. Like I said, I think > from struct ..._if_ap you only have the vlan list that you don't want? I'd rather just factor all the PS data out for now, and maintain the beacon separately. Is there Is there any good reason we'd want to lump these two together? ieee80211_beacon_add_tim() for example already treats these as separate. > > johannes > > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
