From: Alex Elder <elder@ieee.org>
To: Julia Lawall <julia.lawall@inria.fr>
Cc: Menna Mahmoud <eng.mennamahmoud.mm@gmail.com>,
gregkh@linuxfoundation.org, outreachy@lists.linux.dev,
johan@kernel.org, elder@kernel.org, linux-kernel@vger.kernel.org,
linux-staging@lists.linux.dev
Subject: Re: [PATCH v2] staging: greybus: use inline function for macros
Date: Tue, 21 Mar 2023 16:09:22 -0500 [thread overview]
Message-ID: <5efa6e6d-8573-31de-639a-d15b2e9deca0@ieee.org> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2303212140480.2919@hadrien>
On 3/21/23 3:43 PM, Julia Lawall wrote:
>
>
> On Tue, 21 Mar 2023, Alex Elder wrote:
>
>> On 3/21/23 1:34 PM, Menna Mahmoud wrote:
>>> Convert `to_gbphy_dev` and `to_gbphy_driver` macros into a
>>> static inline function.
>>>
>>> It is not great to have macros that use the `container_of` macro,
>>> because from looking at the definition one cannot tell what type
>>> it applies to.
>>>
>>> One can get the same benefit from an efficiency point of view
>>> by making an inline function.
>>>
>>> Suggested-by: Julia Lawall <julia.lawall@inria.fr>
>>> Signed-off-by: Menna Mahmoud <eng.mennamahmoud.mm@gmail.com>
>>
>> I'm sorry if this conflicts with what others have said.
>>
>> But the use of a macro (with a container_of() right-hand
>> side) to get at the structure containing a field pointer
>> is a widely-used idiom throughout the kernel.
>>
>> What you propose achieves the same result but I would
>> lean toward keeping it as a macro, mainly because it
>> is so common.
>
> Common is not necessarily good. Macros are less safe and less
> informative.
I do agree that the inline function is better, and
is functionally equivalent (while being explicit
with types and avoiding any macro expansion funny
business).
Do you think we should make changes like this throughout
the kernel (along the lines of the flexible array fixes,
to make things safer)? I don't think it's a terrible idea,
but it's likely a big undertaking and I predict push-back.
Bottom line on this is that I don't think the proposed
change is wrong, but there is value in consistently
adhering to conventions.
Others can comment; I have no real objection.
-Alex
>
> julia
>
>
>>
>> -Alex
>>> ---
>>> changes in v2:
>>> -send patch as a single patch.
>>> -edit the name of struct object.
>>> -edit commit message.
>>> ---
>>> drivers/staging/greybus/gbphy.h | 10 ++++++++--
>>> 1 file changed, 8 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/staging/greybus/gbphy.h
>>> b/drivers/staging/greybus/gbphy.h
>>> index d4a225b76338..e7ba232bada1 100644
>>> --- a/drivers/staging/greybus/gbphy.h
>>> +++ b/drivers/staging/greybus/gbphy.h
>>> @@ -15,7 +15,10 @@ struct gbphy_device {
>>> struct list_head list;
>>> struct device dev;
>>> };
>>> -#define to_gbphy_dev(d) container_of(d, struct gbphy_device, dev)
>>> +static inline struct gbphy_device *to_gbphy_dev(const struct device *_dev)
>>> +{
>>> + return container_of(_dev, struct gbphy_device, dev);
>>> +}
>>> static inline void *gb_gbphy_get_data(struct gbphy_device *gdev)
>>> {
>>> @@ -43,7 +46,10 @@ struct gbphy_driver {
>>> struct device_driver driver;
>>> };
>>> -#define to_gbphy_driver(d) container_of(d, struct gbphy_driver, driver)
>>> +static inline struct gbphy_driver *to_gbphy_driver(struct device_driver
>>> *drv)
>>> +{
>>> + return container_of(drv, struct gbphy_driver, driver);
>>> +}
>>> int gb_gbphy_register_driver(struct gbphy_driver *driver,
>>> struct module *owner, const char *mod_name);
>>
>>
next prev parent reply other threads:[~2023-03-21 21:09 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-21 18:34 [PATCH v2] staging: greybus: use inline function for macros Menna Mahmoud
2023-03-21 18:50 ` Alex Elder
2023-03-21 20:43 ` Julia Lawall
2023-03-21 21:09 ` Alex Elder [this message]
2023-03-21 21:29 ` Julia Lawall
2023-03-21 22:42 ` Alex Elder
2023-03-22 10:00 ` Julia Lawall
2023-03-22 12:39 ` Alex Elder
2023-03-23 4:58 ` Greg KH
2023-03-23 5:05 ` Deepak R Varma
2023-03-23 5:22 ` Greg KH
2023-03-23 19:46 ` Deepak R Varma
2023-03-23 9:52 ` Julia Lawall
2023-03-25 8:49 ` Greg KH
2023-03-25 9:28 ` Julia Lawall
2023-03-22 9:13 ` Greg KH
-- strict thread matches above, loose matches on Subject: below --
2023-03-19 20:49 Menna Mahmoud
2023-03-19 20:56 ` Julia Lawall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5efa6e6d-8573-31de-639a-d15b2e9deca0@ieee.org \
--to=elder@ieee.org \
--cc=elder@kernel.org \
--cc=eng.mennamahmoud.mm@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=johan@kernel.org \
--cc=julia.lawall@inria.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=outreachy@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox