Subject: Re: [PATCH 02/23] usb-gadget: use per-attribute show and store methods

From: Felipe Balbi <[email-masked]>
Date: Wed, 30 Sep 2015 11:43:01 -0500

On Wed, Sep 30, 2015 at 12:35:38PM -0400, Tejun Heo wrote:
> On Wed, Sep 30, 2015 at 11:32:19AM -0500, Felipe Balbi wrote:
> > On Wed, Sep 30, 2015 at 12:20:46PM -0400, Tejun Heo wrote:
> > > On Wed, Sep 30, 2015 at 11:19:25AM -0500, Felipe Balbi wrote:
> > > > On Mon, Sep 28, 2015 at 03:35:14PM +0200, Christoph Hellwig wrote:
> > > > > On Sun, Sep 27, 2015 at 10:50:53AM -0500, Felipe Balbi wrote:
> > > > > > this (and the other helper below) could be macros just fine.
> > > > > 
> > > > > They could, but they shouldn't.  Inlines are always preferable over
> > > > > function-like macros.
> > > > 
> > > > says who ? And why ?
> > > 
> > > Documentation/CodingStyle
> > 
> > container_of() is type-safe, what is an inline function bringing as benefit ?
> 
> It's a general preference.  Because there's enough benefit to going
> with inline functions and there's extra benefit to be gained from
> having consistent style of code and documentation, as a general rule,
> we prefer inline functions over macros.  If you have specific
> technical arguments why macro is better, sure; otherwise, follow the
> conventions for consistency if for nothing else.

$ git grep -e "define.*container_of"  | wc -l
1003

Seems like there are *ton* of uses of container_of() wrapped within a simple
macro. What convention are you talking about, again ?

And again, what benefit is an inline function bringing in this specific
case ? As for a technical reason, we know the macro definition will be
copied Verbatim into the caller body. GCC might decide to not inline
those helpers (unlikely, but could).

-- 
balbi