Messages in this thread | | | From | Jes Sorensen <> | Subject | Re: [PATCH 3/8] rtl8192u: don't trample on <linux/ieee80211.h> struct namespace | Date | Thu, 30 Apr 2015 10:30:48 -0400 |
| |
Paul Gortmaker <paul.gortmaker@windriver.com> writes: > [Re: [PATCH 3/8] rtl8192u: don't trample on <linux/ieee80211.h> struct > namespace] On 30/04/2015 (Thu 09:52) Jes Sorensen wrote: > >> Paul Gortmaker <paul.gortmaker@windriver.com> writes: >> > In order to start reducing the duplicated code/constants/macros in this >> > driver, we need to include <linux/ieee80211.h> to provide the defacto >> > versions. However this driver has structs with the same name as the >> > ones in the main include, so namespace collision prevents us from doing >> > step #1. >> > >> > Since the structs actually differ in their respective fields, we can't >> > simply delete the local ones without impacting the runtime; a conversion >> > to use the global ones can be considered at a later date if desired. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> > >> > Rename the ones here with a vendor specific prefix so that we won't have >> > the namespace collision, and hence can continue on with the cleanup. >> > >> > Automated conversion done with: >> > >> > for i in `find . -name '*.[ch]'` ; do \ >> > sed -i 's/struct ieee80211_hdr/struct rtl_80211_hdr/g' $i ; \ >> > done >> > >> > Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> >> > --- >> > drivers/staging/rtl8192u/ieee80211/ieee80211.h | 44 +++++++------- >> > .../rtl8192u/ieee80211/ieee80211_crypt_ccmp.c | 10 ++-- >> > .../rtl8192u/ieee80211/ieee80211_crypt_tkip.c | 26 ++++----- >> > drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c | 68 > +++++++++++----------- >> > .../staging/rtl8192u/ieee80211/ieee80211_softmac.c | 32 +++++----- >> > drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c | 14 ++--- >> > .../staging/rtl8192u/ieee80211/rtl819x_BAProc.c | 48 +++++++-------- >> > drivers/staging/rtl8192u/r8192U_core.c | 12 ++-- >> > 8 files changed, 127 insertions(+), 127 deletions(-) >> >> Rather than just renaming these headers to avoid the conflict, it seems >> to me the better solution is to convert the code to use the ieee80211.h >> provided ones from the kernel? > > That is what I said in paragraph #2 above. If someone wants to do this > later, then fine. And then it can be done incrementally and tested by > someone who has the actual hardware. In the meantime, this is better > than what was there, and since it is in staging, a realisitc expectation > is multiple small incremental improvements IMHO.
Sorry too far behind on emails, I missed that part.
I am fine with this approach - we just need a volunteer!
Jes
| |