Re: [PATCH 2/2] staging: rtl8192u: remove unused macro definition

[Deepak R Varma]

On Mon, Oct 31, 2022 at 03:55:59PM +0100, Julia Lawall wrote:
>
>
> On Mon, 31 Oct 2022, Deepak R Varma wrote:
>
> > On Fri, Oct 28, 2022 at 01:03:36AM +0530, Deepak Varma wrote:
> > > On Wed, Oct 26, 2022 at 03:55:01PM +0200, Greg Kroah-Hartman wrote:
> > > > On Wed, Oct 26, 2022 at 07:14:43PM +0530, Deepak R Varma wrote:
> > > > > On Wed, Oct 26, 2022 at 03:14:23PM +0200, Greg Kroah-Hartman wrote:
> > > > > > On Wed, Oct 26, 2022 at 08:58:44AM +0530, Deepak R Varma wrote:
> > > > > > > Pre-processor macros that are defined but are never used should be
> > > > > > > cleaned up to avoid unexpected usage.
> > > > > > >
> > > > > > > Signed-off-by: Deepak R Varma <drv@xxxxxxxxx>
> > > > > > > ---
> > > > > > >  drivers/staging/rtl8192u/ieee80211/ieee80211.h | 2 --
> > > > > > >  1 file changed, 2 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211.h b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
> > > > > > > index 00c07455cbb3..0b3dda59d7c0 100644
> > > > > > > --- a/drivers/staging/rtl8192u/ieee80211/ieee80211.h
> > > > > > > +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
> > > > > > > @@ -230,8 +230,6 @@ struct cb_desc {
> > > > > > >  #define ieee80211_unregister_crypto_ops ieee80211_unregister_crypto_ops_rsl
> > > > > > >  #define ieee80211_get_crypto_ops	ieee80211_get_crypto_ops_rsl
> > > > > > >
> > > > > > > -#define ieee80211_ccmp_null		ieee80211_ccmp_null_rsl
> > > > > > > -
> > > > > > >  #define free_ieee80211			free_ieee80211_rsl
> > > > > > >  #define alloc_ieee80211			alloc_ieee80211_rsl
> > > > > >
> > > > > > These #defines are a mess, please look into unwinding them as they
> > > > > > should not be needed at all.
> > > > >
> > > > > Hello Greg,
> > > > > I would like to know what you mean by "unwind them". Is there a documentation or past
> > > > > commit that I can review to understand the expectations better?
> > > >
> > > > Look at them and try to figure out why they are there, and then work to
> > > > remove them entirely.  A define like this is very odd in the kernel, it
> > > > should not be needed at all, right?
> > >
> > > Hello Greg,
> > > I will look into these additional macros soon and send any further edits as a
> > > separate patch (set). Is the current patch set with 2 patches acceptable?
> > >
> > > Also, I am trying to get Coccinelle to work on my machine. Trying to work
> > > through strange issues. I will work on the macro unwinding task you suggested
> > > once a get the Coccinelle task completed.
> >
> > Hello Greg,
> > Most of these macro defines appear to be unused in the module anywhere.
> > I can simply delete the #defines for these and let the original function
> > names be retained.
> > The other way is to rename the functions by the defined value. So, we will have
> > to make the code change to use the foo_rsl symbol names at all places. This will
> > be a bigger change involving the API name change itself.
>
> I'm not sure to understand.  In the case of

My apologies for not being clear in my message.
>
> #define abc def
>
> If abc is never used, it would seem that you could just remove the macro
> definition.

The module uses abc at all places in the code. It gets simply replaced by
abc_rsl symbol name at compile time. I am unable to determine the utility of
this compile time conversion. So, to clean it up, we can continue to use abc
in the code (by simply removing the #define line) or make code changes to use
abc_rsl (makes the #define line redundant and be deleted).

Hope this helps.
My question: should we use abc or def in the code? The only hint I have form the
code comment is this line:
	// added for kernel conflict

>
> If abc is used, one might consider whether the renaming is worth it, or
> whether the abc's should be changed to def.  Or maybe def is a very simple
> function, that just calls some standard kernel function like kfree, in
> which can you could get rid of both abc and def everywhere and just use
> kfree.
>
> It is often better to use standard functions, because it makes it easier
> for people to understand immediately what is going on.

Thank you so much for the explanation. Since the initial intention is not clear
to me, I am unable to decide the go forward name for these functions.

May I request to look at one of the macro implementations and make suggestion?

>
> julia
>
>
> >
> > I am unable to determine the initial intention as to why these #defines were
> > added. Can you please suggest what would be the recommended way for the clean up
> > of these unused macros?
> >
> > Thank you,
> > ./drv
> >
> > >
> > > Thank you,
> > > ./drv
> > >
> > > >
> > > > thanks,
> > > >
> > > > greg k-h
> > > >
> > >
> > >
> > >
> >
> >
> >
> >