netdev - Re: d80211: The struct ieee80211_hw

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 13 Dec 2006 12:23:00 +0100
From:	"Ivo Van Doorn" <ivdoorn@...il.com>
To:	"Michael Buesch" <mb@...sch.de>
Cc:	"Jiri Benc" <jbenc@...e.cz>, netdev@...r.kernel.org
Subject: Re: d80211: The struct ieee80211_hw_modes array is a pain

Hi,

> I am currently porting the bcm43xx driver to my new Sonics
> Silicon Backplane busdriver.
> I am having a major pain implementing the hw->modes field
> for this. In particular, the problem is allocation.
> I always felt sick about hw->modes, but with my new code it's
> damn complicated to get allocation of the stuff right.
> The problem is, that I do not know in advance which PHYMODEs
> my device supports (in fact, we never knew that, but we worked
> around it (in a broken way)).
> We have the following scenario: The PHYs are probed one after
> each other. We have one data structure per PHY. This bites
> the static hw->modes array in its ass. I would either have to
> allocate it "big enough" at the first time (wasting lots of memory)
> or I'd have to re-allocate it every time a new PHY is probed.
> Another (much harder to fix) problem is the opposite of the probing:
> Removing the PHYs.
>
> So, what I'd like to have is:
>
> One struct ieee802111_hw_mode which I can embed into the PHY
> data structure. This struct is now dynamically registered to the
> ieee80211 subsystem (instead of doing a static array pain).
>
> Registering and unregistering would be done with simple linked lists,
> perhaps, in d80211.

Sounds good to me. This would also solve the issue where the dscape stack
would always select the first mode in the array as the default mode.
Which means that the array should always be allocated in a specific
order since if B is first followed by G, then B would always be used
(even if G is supported by the AP).

Ivo
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html