Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Coiby Xu <coiby.xu@gmail.com>
Date:   Mon, 19 Oct 2020 10:12:16 +0800
To:     Benjamin Poirier <benjamin.poirier@gmail.com>
Cc:     devel@driverdev.osuosl.org, Shung-Hsi Yu <shung-hsi.yu@suse.com>,
        Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
        Dan Carpenter <dan.carpenter@oracle.com>,
        Manish Chopra <manishc@marvell.com>,
        "supporter:QLOGIC QLGE 10Gb ETHERNET DRIVER" 
        <GR-Linux-NIC-Dev@marvell.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "open list:QLOGIC QLGE 10Gb ETHERNET DRIVER" <netdev@vger.kernel.org>,
        open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 1/7] staging: qlge: replace ql_* with qlge_* to avoid
 namespace clashes with other qlogic drivers
Message-ID: <20201019021216.we4py3d2kqesaa6i@Rk>
References: <20201014104306.63756-1-coiby.xu@gmail.com>
 <20201014104306.63756-2-coiby.xu@gmail.com>
 <20201015010136.GB31835@f3>
 <20201016231631.efwu5a4a5f3jnrzv@Rk>
 <20201018110253.GA21325@f3>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <20201018110253.GA21325@f3>
Precedence: bulk

On Sun, Oct 18, 2020 at 08:02:53PM +0900, Benjamin Poirier wrote:
>On 2020-10-17 07:16 +0800, Coiby Xu wrote:
>> On Thu, Oct 15, 2020 at 10:01:36AM +0900, Benjamin Poirier wrote:
>> > On 2020-10-14 18:43 +0800, Coiby Xu wrote:
>> > > To avoid namespace clashes with other qlogic drivers and also for the
>> > > sake of naming consistency, use the "qlge_" prefix as suggested in
>> > > drivers/staging/qlge/TODO.
>> > >
>> > > Suggested-by: Benjamin Poirier <benjamin.poirier@gmail.com>
>> > > Signed-off-by: Coiby Xu <coiby.xu@gmail.com>
>> > > ---
>> > >  drivers/staging/qlge/TODO           |    4 -
>> > >  drivers/staging/qlge/qlge.h         |  190 ++--
>> > >  drivers/staging/qlge/qlge_dbg.c     | 1073 ++++++++++++-----------
>> > >  drivers/staging/qlge/qlge_ethtool.c |  231 ++---
>> > >  drivers/staging/qlge/qlge_main.c    | 1257 +++++++++++++--------------
>> > >  drivers/staging/qlge/qlge_mpi.c     |  352 ++++----
>> > >  6 files changed, 1551 insertions(+), 1556 deletions(-)
>> > >
>> > > diff --git a/drivers/staging/qlge/TODO b/drivers/staging/qlge/TODO
>> > > index f93f7428f5d5..5ac55664c3e2 100644
>> > > --- a/drivers/staging/qlge/TODO
>> > > +++ b/drivers/staging/qlge/TODO
>> > > @@ -28,10 +28,6 @@
>> > >  * the driver has a habit of using runtime checks where compile time checks are
>> > >    possible (ex. ql_free_rx_buffers(), ql_alloc_rx_buffers())
>> > >  * reorder struct members to avoid holes if it doesn't impact performance
>> > > -* in terms of namespace, the driver uses either qlge_, ql_ (used by
>> > > -  other qlogic drivers, with clashes, ex: ql_sem_spinlock) or nothing (with
>> > > -  clashes, ex: struct ob_mac_iocb_req). Rename everything to use the "qlge_"
>> > > -  prefix.
>> >
>> > You only renamed ql -> qlge. The prefix needs to be added where there is
>> > currently none like the second example of that text.
>>
>> On second thoughts, these structs like ob_mac_iocb_req are defined in
>> local headers and there is no mixed usage. So even when we want to
>> build this diver and other qlogic drivers into the kernel instead of
>> as separate modules, it won't lead to real problems, is it right?
>
>Using cscope or ctags and searching for ob_mac_iocb_req will yield
>ambiguous results. It might also make things more difficult if using a
>debugger.
>
Even if I have been using gtags, I didn't realize it. Thank you for
explaining it to me.
>Looking at other drivers (ex. ice, mlx5), they use a prefix for their
>private types, just like for their static functions, even though it's
>not absolutely necessary. I think it's helpful when reading the code
>because it quickly shows that it is something that was defined in the
>driver, not in some subsystem.
>
Good point!

>I didn't think about it earlier but it would have been better to leave
>out this renaming to a subsequent patchset, since this change is
>unrelated to the debugging features.

It seems it's more reasonable to do renaming first. So in a sense, the
renaming is a preparatory step for the debugging features.

--
Best regards,
Coiby