From: Ben Pfaff <blp@ovn•org>
To: Gregory Rose <gvrose8192@gmail•com>
Cc: Eli Britstein <elibr@mellanox•com>,
David Miller <davem@davemloft•net>,
"yihung.wei@gmail•com" <yihung.wei@gmail•com>,
"dev@openvswitch•org" <dev@openvswitch•org>,
"netdev@vger•kernel.org" <netdev@vger•kernel.org>,
"simon.horman@netronome•com" <simon.horman@netronome•com>
Subject: Re: [ovs-dev] [PATCH net-next V2 1/1] openvswitch: Declare ovs key structures using macros
Date: Tue, 5 Feb 2019 12:23:16 -0800 [thread overview]
Message-ID: <20190205202316.GS27607@ovn.org> (raw)
In-Reply-To: <c3455573-5dad-e7a7-fc89-15312c0b7c88@gmail.com>
On Tue, Feb 05, 2019 at 10:22:09AM -0800, Gregory Rose wrote:
>
> 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.wei@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.
In addition, one of the reasons that developers prefer to avoid
duplication is because of the need to synchronize copies when one of
them changes. This doesn't apply in the same way to these structures,
because they are ABIs that will not change.
next prev parent reply other threads:[~2019-02-05 20:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-03 9:12 [PATCH net-next V2 1/1] openvswitch: Declare ovs key structures using macros Eli Britstein
2019-02-04 5:55 ` Pravin Shelar
2019-02-04 18:47 ` [ovs-dev] " Yi-Hung Wei
2019-02-04 20:07 ` David Miller
2019-02-05 12:02 ` Eli Britstein
2019-02-05 18:22 ` Gregory Rose
2019-02-05 20:23 ` Ben Pfaff [this message]
2019-02-07 5:47 ` Eli Britstein
2019-02-04 19:41 ` Gregory Rose
2019-02-04 20:09 ` David Miller
2019-02-08 7:59 ` Simon Horman
2019-02-08 9:33 ` Eli Britstein
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190205202316.GS27607@ovn.org \
--to=blp@ovn$(echo .)org \
--cc=davem@davemloft$(echo .)net \
--cc=dev@openvswitch$(echo .)org \
--cc=elibr@mellanox$(echo .)com \
--cc=gvrose8192@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=simon.horman@netronome$(echo .)com \
--cc=yihung.wei@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox