On 2/4/2019 10:07 PM, David Miller wrote:
> From: Yi-Hung Wei <yihung....@gmail.com>
> Date: Mon, 4 Feb 2019 10:47:18 -0800
>
>> For example, to see how 'struct ovs_key_ipv6' is defined, now we need
>> to trace how OVS_KEY_IPV6_FIELDS is defined, and how OVS_KEY_FIELD_ARR
>> and OVS_KEY_FIELD defined. I think it makes the header file to be
>> more complicated.
> I completely agree.
>
> Unless this is totally unavoidable, I do not want to apply a patch
> which makes reading and auditing the networking code more difficult.
This technique is discussed for example in
https://stackoverflow.com/questions/6635851/real-world-use-of-x-macros,
and I found existing examples of using it in the kernel tree:
__BPF_FUNC_MAPPER in commit ebb676daa1a34 ("bpf: Print function name in
addition to function id")
__AAL_STAT_ITEMS and __SONET_ITEMS in commit 607ca46e97a1b ("UAPI:
(Scripted) Disintegrate include/linux"), the successor of commit
1da177e4c3f4 ("Linux-2.6.12-rc2"). I didn't dig deeper to the past.
I can agree it makes that H file a bit more complicated, but for sure
less than ## macros that are widely used.
However, I think the alternatives of generating such defines by some
scripts, or having the fields in more than one place are even worse, so
it is a kind of unavoidable.
Please reconsider regarding applying this patch.
