From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from msg-4.mailo.com (msg-4.mailo.com [213.182.54.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3A5667E; Mon, 31 Oct 2022 16:08:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mailo.com; s=mailo; t=1667232491; bh=5EkPScDX72GkCEG4LAOwMGll0UXL+JQdTsSUibmILmI=; h=X-EA-Auth:Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:In-Reply-To; b=Iv0DpmE1aTGkZkQ6qlcF1ooPbEFh9uxFkW5oqVNoH96MxUO2kDD2ExU/eEoIXSuYQ +mED5TVjDo/XM0PR+2fCxluFm41bU/GxhJKEN4n5Ux7o38GAl8GquAXMRO9sLGcEAk FmeyiZtmte06yajrMMcc/HEkTFa5LNy18FokgG7o= Received: by b-4.in.mailobj.net [192.168.90.14] with ESMTP via [213.182.55.206] Mon, 31 Oct 2022 17:08:11 +0100 (CET) X-EA-Auth: P5JcrFa6GKLN/QbfWpesGZ7fl1WEe/RoceVkCX+gwIIvcH6s1ftjBnHLh0Cr2fzhXb/znX4Nlt9Nn2gseV5AVIUG1c5IbUyL Date: Mon, 31 Oct 2022 21:38:12 +0530 From: Deepak R Varma To: Julia Lawall Cc: Greg Kroah-Hartman , outreachy@lists.linux.dev, linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] staging: rtl8192u: remove unused macro definition Message-ID: References: <58624e76-aea8-4ed4-d6e-106cf77d629b@inria.fr> Precedence: bulk X-Mailing-List: linux-staging@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58624e76-aea8-4ed4-d6e-106cf77d629b@inria.fr> 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 > > > > > > > > > --- > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >