[U-Boot] [PATCH v2 06/12] USB: gadget: added a saner gadget downloader registration API

[Marek Vasut]

On Thursday, February 06, 2014 at 12:56:58 PM, Mateusz Zalega wrote:
> On 02/05/14 19:00, Marek Vasut wrote:
> > On Wednesday, February 05, 2014 at 01:40:27 PM, Mateusz Zalega wrote:
> > 
> > [...]
> > 
> >>> Are these two new functions called from multiple places at all? If not,
> >>> just inline these ll_foo() calls and be done with it. FYI you can also
> >>> make macros for these to avoid having to type all these args all around
> >>> and duplicating the code.
> >> 
> >> Macros or static inlines, it's all the same
> > 
> > NAK, what you say is seriously wrong, you should know that by now!
> > 
> > Macros do not do any kind of typechecking, functions do typechecking.
> > Macros are expanded in place during preprocessing, functions are
> > (usually) single-instance.
> > 
> > etc.
> 
> Yeah, and it's all the same if you don't care for typechecking and all
> that, which I assumed from _you_ proposing usage of macros here.

You will need macros wherever you do some kind of strange expansion. If you 
don't need to do strange expansion, use inline functions wherever possible. But 
I think in case of the linker generated lists, you really cannot avoid using 
macros.

> >> there's no point in
> >> changing that. The symbols aren't visible outside this compilation unit
> >> and function calls are, well, inlined.
> > 
> > It's pointless to have them pulled out so explicitly. Or would you prefer
> > to have each function encapsulated in another function ? This doesn't
> > make does now, does it ?
> 
> Pardon?

Sure ...

Actually, looking at this, you are right that wrapping the LL macro with a 
function is a good idea.

> > What I would like to do is for you to follow the advice in linker_lists.h
> > and produce a small shim over these crude linker lists prototypes there,
> > so that the users here in the g_* world don't have to type the whole
> > linker list macros with all the arguments, which do not ever change for
> > this g_* . Does it make sense please?
> 
> It's taken care of by static inlines.

Yes OK, you do have a point.

[...]

> >>> instead to make sure you don't step onto a corrupted field and crash in
> >>> some weird way.
> >> 
> >> Linker would have to split sections to make this sort of thing possible.
> >> Won't happen.
> > 
> > Can you please elaborate ?
> > [...]
> 
> You're guaranteed by the linker, and our setup, that all your
> linker-list data will end up in a contiguous block.

This doesn't mean someone won't corrupt it, but that's for an entirely different 
discussion I'd say.