Re: [PATCH 3/8] rtl8192u: don't trample on struct namespace
Paul Gortmaker writes: > [Re: [PATCH 3/8] rtl8192u: don't trample on struct > namespace] On 30/04/2015 (Thu 09:52) Jes Sorensen wrote: > >> Paul Gortmaker writes: >> > In order to start reducing the duplicated code/constants/macros in this >> > driver, we need to include 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 >> > --- >> > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] rtl8192u: don't trample on struct namespace
[Re: [PATCH 3/8] rtl8192u: don't trample on struct
namespace] On 30/04/2015 (Thu 09:52) Jes Sorensen wrote:
> Paul Gortmaker writes:
> > In order to start reducing the duplicated code/constants/macros in this
> > driver, we need to include 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
> > ---
> > 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.
Paul.
--
>
> Cheers,
> Jes
>
> > diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211.h
> > b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
> > index 0f53c6a97578..bdad6d07c574 100644
> > --- a/drivers/staging/rtl8192u/ieee80211/ieee80211.h
> > +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
> > @@ -1020,20 +1020,20 @@ enum ieee80211_mfie {
> > /* Minimal header; can be used for passing 802.11 frames with sufficient
> > * information to determine what type of underlying data type is actually
> > * stored in the data. */
> > -struct ieee80211_hdr {
> > +struct rtl_80211_hdr {
> > __le16 frame_ctl;
> > __le16 duration_id;
> > u8 payload[0];
> > } __packed;
> >
> > -struct ieee80211_hdr_1addr {
> > +struct rtl_80211_hdr_1addr {
> > __le16 frame_ctl;
> > __le16 duration_id;
> > u8 addr1[ETH_ALEN];
> > u8 payload[0];
> > } __packed;
> >
> > -struct ieee80211_hdr_2addr {
> > +struct rtl_80211_hdr_2addr {
> > __le16 frame_ctl;
> > __le16 duration_id;
> > u8 addr1[ETH_ALEN];
> > @@ -1041,7 +1041,7 @@ struct ieee80211_hdr_2addr {
> > u8 payload[0];
> > } __packed;
> >
> > -struct ieee80211_hdr_3addr {
> > +struct rtl_80211_hdr_3addr {
> > __le16 frame_ctl;
> > __le16 duration_id;
> > u8 addr1[ETH_ALEN];
> > @@ -1051,7 +1051,7 @@ struct ieee80211_hdr_3addr {
> > u8 payload[0];
> > } __packed;
> >
> > -struct ieee80211_hdr_4addr {
> > +struct rtl_80211_hdr_4addr {
> > __le16 frame_ctl;
> > __le16 duration_id;
> > u8 addr1[ETH_ALEN];
> > @@ -1062,7 +1062,7 @@ struct ieee80211_hdr_4addr {
> > u8 payload[0];
> > } __packed;
> >
> > -struct ieee80211_hdr_3addrqos {
> > +struct rtl_80211_hdr_3addrqos {
> > __le16 frame_ctl;
> > __le16 duration_id;
> > u8 addr1[ETH_ALEN];
> > @@ -1073,7 +1073,7 @@ struct ieee80211_hdr_3addrqos {
> > __le16 qos_ctl;
> > } __packed;
> >
> > -struct ieee80211_hdr_4addrqos {
> > +struct rtl_80211_hdr_4addrqos {
> > __le16 frame_ctl;
> > __le16 duration_id;
> > u8 addr1[ETH_ALEN];
> > @@ -109
Re: [PATCH 3/8] rtl8192u: don't trample on struct namespace
Paul Gortmaker writes:
> In order to start reducing the duplicated code/constants/macros in this
> driver, we need to include 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
> ---
> 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?
Cheers,
Jes
> diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211.h
> b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
> index 0f53c6a97578..bdad6d07c574 100644
> --- a/drivers/staging/rtl8192u/ieee80211/ieee80211.h
> +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
> @@ -1020,20 +1020,20 @@ enum ieee80211_mfie {
> /* Minimal header; can be used for passing 802.11 frames with sufficient
> * information to determine what type of underlying data type is actually
> * stored in the data. */
> -struct ieee80211_hdr {
> +struct rtl_80211_hdr {
> __le16 frame_ctl;
> __le16 duration_id;
> u8 payload[0];
> } __packed;
>
> -struct ieee80211_hdr_1addr {
> +struct rtl_80211_hdr_1addr {
> __le16 frame_ctl;
> __le16 duration_id;
> u8 addr1[ETH_ALEN];
> u8 payload[0];
> } __packed;
>
> -struct ieee80211_hdr_2addr {
> +struct rtl_80211_hdr_2addr {
> __le16 frame_ctl;
> __le16 duration_id;
> u8 addr1[ETH_ALEN];
> @@ -1041,7 +1041,7 @@ struct ieee80211_hdr_2addr {
> u8 payload[0];
> } __packed;
>
> -struct ieee80211_hdr_3addr {
> +struct rtl_80211_hdr_3addr {
> __le16 frame_ctl;
> __le16 duration_id;
> u8 addr1[ETH_ALEN];
> @@ -1051,7 +1051,7 @@ struct ieee80211_hdr_3addr {
> u8 payload[0];
> } __packed;
>
> -struct ieee80211_hdr_4addr {
> +struct rtl_80211_hdr_4addr {
> __le16 frame_ctl;
> __le16 duration_id;
> u8 addr1[ETH_ALEN];
> @@ -1062,7 +1062,7 @@ struct ieee80211_hdr_4addr {
> u8 payload[0];
> } __packed;
>
> -struct ieee80211_hdr_3addrqos {
> +struct rtl_80211_hdr_3addrqos {
> __le16 frame_ctl;
> __le16 duration_id;
> u8 addr1[ETH_ALEN];
> @@ -1073,7 +1073,7 @@ struct ieee80211_hdr_3addrqos {
> __le16 qos_ctl;
> } __packed;
>
> -struct ieee80211_hdr_4addrqos {
> +struct rtl_80211_hdr_4addrqos {
> __le16 frame_ctl;
> __le16 duration_id;
> u8 addr1[ETH_ALEN];
> @@ -1092,7 +1092,7 @@ struct ieee80211_info_element {
> } __packed;
>
> struct ieee80211_authentication {
> - struct ieee80211_hdr_3addr header;
> + struct rtl_80211_hdr_3addr header;
> __le16 algorithm;
> __le16 transaction;
> __le16 status;
> @@ -1101,18 +1101,18 @@ struct ieee80211_authentication {
> } __packed;
>
> struct ieee80211_disassoc {
> - struct ieee80211_hdr_3addr header;
> + struct rtl_80211_hdr_3addr header;
> __le16 reason;
> } __packed;
>
> struct ieee80211_probe_request {
> - struct ieee80211_hdr_3addr header;
> + struct rtl_80211_hdr_3addr header;
> /* SSID, supported rates */
> struct ieee80211_info_element info_element[0];
> } __packed;
>
> struct ieee80211_probe_response {
> - struct ieee80211_hdr_3addr header;
> + struct rtl_80211_hdr_3addr header;
> __le32 time_stamp[2];
> __le16 beacon_interval;
> __le16 capability;
> @@ -1125,7 +1125,7 @@ struct ieee80211_probe_response {
> #define ieee80211_beacon ieee80211_probe_response
>
> struct ieee80211_assoc_request_frame {
> - struct ieee80211_hdr_3addr header;
> + struct rtl_80211_hdr_3addr header;
> __le16 capability;
> __le16 listen_interval;
> /* SSID, supported rates, RSN */
> @@ -1133,7 +1133,7 @@ struct ieee80211_assoc_
[PATCH 3/8] rtl8192u: don't trample on struct namespace
In order to start reducing the duplicated code/constants/macros in this
driver, we need to include 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
---
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(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211.h
b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
index 0f53c6a97578..bdad6d07c574 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211.h
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
@@ -1020,20 +1020,20 @@ enum ieee80211_mfie {
/* Minimal header; can be used for passing 802.11 frames with sufficient
* information to determine what type of underlying data type is actually
* stored in the data. */
-struct ieee80211_hdr {
+struct rtl_80211_hdr {
__le16 frame_ctl;
__le16 duration_id;
u8 payload[0];
} __packed;
-struct ieee80211_hdr_1addr {
+struct rtl_80211_hdr_1addr {
__le16 frame_ctl;
__le16 duration_id;
u8 addr1[ETH_ALEN];
u8 payload[0];
} __packed;
-struct ieee80211_hdr_2addr {
+struct rtl_80211_hdr_2addr {
__le16 frame_ctl;
__le16 duration_id;
u8 addr1[ETH_ALEN];
@@ -1041,7 +1041,7 @@ struct ieee80211_hdr_2addr {
u8 payload[0];
} __packed;
-struct ieee80211_hdr_3addr {
+struct rtl_80211_hdr_3addr {
__le16 frame_ctl;
__le16 duration_id;
u8 addr1[ETH_ALEN];
@@ -1051,7 +1051,7 @@ struct ieee80211_hdr_3addr {
u8 payload[0];
} __packed;
-struct ieee80211_hdr_4addr {
+struct rtl_80211_hdr_4addr {
__le16 frame_ctl;
__le16 duration_id;
u8 addr1[ETH_ALEN];
@@ -1062,7 +1062,7 @@ struct ieee80211_hdr_4addr {
u8 payload[0];
} __packed;
-struct ieee80211_hdr_3addrqos {
+struct rtl_80211_hdr_3addrqos {
__le16 frame_ctl;
__le16 duration_id;
u8 addr1[ETH_ALEN];
@@ -1073,7 +1073,7 @@ struct ieee80211_hdr_3addrqos {
__le16 qos_ctl;
} __packed;
-struct ieee80211_hdr_4addrqos {
+struct rtl_80211_hdr_4addrqos {
__le16 frame_ctl;
__le16 duration_id;
u8 addr1[ETH_ALEN];
@@ -1092,7 +1092,7 @@ struct ieee80211_info_element {
} __packed;
struct ieee80211_authentication {
- struct ieee80211_hdr_3addr header;
+ struct rtl_80211_hdr_3addr header;
__le16 algorithm;
__le16 transaction;
__le16 status;
@@ -1101,18 +1101,18 @@ struct ieee80211_authentication {
} __packed;
struct ieee80211_disassoc {
- struct ieee80211_hdr_3addr header;
+ struct rtl_80211_hdr_3addr header;
__le16 reason;
} __packed;
struct ieee80211_probe_request {
- struct ieee80211_hdr_3addr header;
+ struct rtl_80211_hdr_3addr header;
/* SSID, supported rates */
struct ieee80211_info_element info_element[0];
} __packed;
struct ieee80211_probe_response {
- struct ieee80211_hdr_3addr header;
+ struct rtl_80211_hdr_3addr header;
__le32 time_stamp[2];
__le16 beacon_interval;
__le16 capability;
@@ -1125,7 +1125,7 @@ struct ieee80211_probe_response {
#define ieee80211_beacon ieee80211_probe_response
struct ieee80211_assoc_request_frame {
- struct ieee80211_hdr_3addr header;
+ struct rtl_80211_hdr_3addr header;
__le16 capability;
__le16 listen_interval;
/* SSID, supported rates, RSN */
@@ -1133,7 +1133,7 @@ struct ieee80211_assoc_request_frame {
} __packed;
struct ieee80211_reassoc_request_frame {
- struct ieee80211_hdr_3addr header;
+ struct rtl_80211_hdr_3addr header;
__le16 capability;
__le16 listen_interval;
u8 current_ap[ETH_ALEN];
@@ -1142,7 +1142,7 @@ struct ieee80211_reassoc_request_frame {
} __packed;
struct ieee80211_assoc_response_frame {
- struct ie
