Why is peer->peer_ids a bitmap?

Michal Kazior michal.kazior at tieto.com
Wed Mar 30 23:37:46 PDT 2016

On 30 March 2016 at 17:42, Ben Greear <greearb at candelatech.com> wrote:
> On 03/30/2016 03:07 AM, Michal Kazior wrote:
>> On 29 March 2016 at 23:30, Ben Greear <greearb at candelatech.com> wrote:
>>> Can a single peer object really have more than one ID?
>> When you install keys you typically get more ids via htt-peer-map
>> event. I think there were some other cases as well..
>>> Is this trying to deal with shared peer objects, perhaps?
>> This was developed very long ago when peer-id mapping wasn't really
>> well understood. Perhaps we could make do without peer id map now?
>> i.e. only care about the first htt-peer-map per peer address?
> The 10.4.3 firmware can probably still do shared peers, though not sure if
> it actually
> happens in practice, and I'm not sure it that would cause this bitmap to
> ever have more than one bit set anyway.
> It just struck me as strange, mainly, and since the radio struct has
> a peer array indexed by the peer-id, then it would seem that we should never
> have duplicate bits set in any of the peer objects.  And, if that is
> correct,
> then the bitmap or similar should probably be in the radio struct instead of
> in peer objects.

Ah, good point. The peer_map[] was introduced recently to allow quick
peer_id -> peer/station translation for pull-push purposes. So yes -
there some duplication going on now. I guess the bitmap could go away.


More information about the ath10k mailing list