From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 79F43C282CC for ; Tue, 5 Feb 2019 20:23:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5540B2073D for ; Tue, 5 Feb 2019 20:23:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729388AbfBEUX0 (ORCPT ); Tue, 5 Feb 2019 15:23:26 -0500 Received: from relay2-d.mail.gandi.net ([217.70.183.194]:39507 "EHLO relay2-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726726AbfBEUXZ (ORCPT ); Tue, 5 Feb 2019 15:23:25 -0500 X-Originating-IP: 208.91.3.26 Received: from ovn.org (unknown [208.91.3.26]) (Authenticated sender: blp@ovn.org) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 5E4EC40008; Tue, 5 Feb 2019 20:23:20 +0000 (UTC) Date: Tue, 5 Feb 2019 12:23:16 -0800 From: Ben Pfaff To: Gregory Rose Cc: Eli Britstein , David Miller , "yihung.wei@gmail.com" , "dev@openvswitch.org" , "netdev@vger.kernel.org" , "simon.horman@netronome.com" Subject: Re: [ovs-dev] [PATCH net-next V2 1/1] openvswitch: Declare ovs key structures using macros Message-ID: <20190205202316.GS27607@ovn.org> References: <20190203091217.8459-1-elibr@mellanox.com> <20190204.120727.1732794761205124286.davem@davemloft.net> <4f57a34c-55a3-ea39-b9cc-2e1dbebc99c1@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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 > > > 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.