On 2/5/2019 4:02 AM, Eli Britstein wrote:
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.
Why is using a script to generate defines for the requirements of your
application or driver so bad? Your patch
turns openvswitch.h into some hardly readable code - using a script and
having a machine output the macros
your application or driver needs seems like a much better alternative to me.
- Greg
Please reconsider regarding applying this patch.
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
