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

[Deepak R Varma <drv@mailo.com>]

On Mon, Oct 31, 2022 at 04:37:38PM +0100, Julia Lawall wrote:
>
>
> On Mon, 31 Oct 2022, Deepak R Varma wrote:
>
> > 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@mailo.com>
> > > > > > > > > ---
> > > > > > > > >  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?
>
> Ah, ok I see, these macros replace both the names at the uses of eg
> free_ieee80211, but also the name at the point of the definition.
>
> But the name free_ieee80211 isn't used elsewhere in the kernel source
> tree, so it would seem that changing the name is useless.
>
> Maybe the purpose was to link this code with some other code that also
> uses the name free_ieee80211, but that other code doesn't seem to be part
> of the kernel.
>
> At least, you could propose a patch that removes these definitions and
> explains clearly what the impact is, and see if the maintainers of the
> driver complain.

Thank you so much. I will send in the proposed patch shortly.

./drv

>
> julia
>
> >
> > >
> > > 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
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> >
> >
> >
>