netdev - Re: [PATCH net-next 0/5] bonding: simple macro cleanup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAADnVQKw3npBoeuQbVf4FtDiqiZuc7+1z7fwUL_6Vru-p3BwDQ@mail.gmail.com>
Date:	Wed, 14 May 2014 09:10:33 -0700
From:	Alexei Starovoitov <alexei.starovoitov@...il.com>
To:	Veaceslav Falico <vfalico@...il.com>
Cc:	David Laight <David.Laight@...lab.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Jay Vosburgh <j.vosburgh@...il.com>,
	Andy Gospodarek <andy@...yhouse.net>,
	Veaceslav Falico <vfalico@...hat.com>
Subject: Re: [PATCH net-next 0/5] bonding: simple macro cleanup

On Wed, May 14, 2014 at 6:29 AM, Veaceslav Falico <vfalico@...il.com> wrote:
> On Wed, May 14, 2014 at 01:08:19PM +0000, David Laight wrote:
>>
>> From: Veaceslav Falico
>>>
>>> Hi,
>>>
>>> That's a trivial patchset that tries to unify the macro usage of bonding
>>> modes. I've split it into two approaches - either BOND_*, which takes
>>> bonding struct as a param, or MODE_*, which takes the mode itself. Also,
>>> introduce BOND_MODE(bond) instead of ugly bond->params.mode.
>>
>>
>> I'm not sure these are improvements....
>>
>> I thought that netdev (in particular) preferred static inline functions
>> to #defines - and especially #defines that expand their argument(s)
>> more than once.
>
>
> There's only one static inline function removal - which was completely
> different from the usual macros (bond_is_lb()). Other macros are just
> renames to quicker understand the code.
>
>
>>
>> IMHO Simple access functions are just a PITA when reading code since
>> they cause the reader to go off somewhere and look up the definition.
>
>
> I can make them either way, I've made this patchset while doing other
> patchset, and the basic idea was that currently the usage of these macros
> is quite illogical - some take bond as an argument, some the mode, and
> there's a function that is a macro...
>
> Anyway, I don't have a strong feeling either way, so if people think that
> it's better the way it is - I'm ok with that.

from compiler point of view it's actually easier to deal with inline functions
than macros. I'd suggest to do the full conversion the other way around:
convert all macros to static inline. Developers will enjoy better type safety
and compiler will enjoy more opportunities to optimize code.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html