From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 2B3F68E69 for ; Wed, 13 Jan 2016 15:24:09 +0100 (CET) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga104.fm.intel.com with ESMTP; 13 Jan 2016 06:24:08 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,289,1449561600"; d="scan'208";a="28643395" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.208.64]) by fmsmga004.fm.intel.com with SMTP; 13 Jan 2016 06:24:06 -0800 Received: by (sSMTP sendmail emulation); Wed, 13 Jan 2016 14:24:05 +0025 Date: Wed, 13 Jan 2016 14:24:05 +0000 From: Bruce Richardson To: Jan Viktorin Message-ID: <20160113142405.GA7756@bricha3-MOBL3> References: <1451938106-12145-1-git-send-email-viktorin@rehivetech.com> <1451938106-12145-4-git-send-email-viktorin@rehivetech.com> <20160113140118.GA16036@bricha3-MOBL3> <20160113151227.6cfcd0a9@pcviktorin.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160113151227.6cfcd0a9@pcviktorin.fit.vutbr.cz> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 03/14] eal/common: introduce union rte_device and related X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 14:24:09 -0000 On Wed, Jan 13, 2016 at 03:12:27PM +0100, Jan Viktorin wrote: > On Wed, 13 Jan 2016 14:01:19 +0000 > Bruce Richardson wrote: > > > On Mon, Jan 04, 2016 at 09:08:15PM +0100, Jan Viktorin wrote: > > > The union rte_device can be used in situations where we want to work with all > > > devices without distinguishing among bus-specific features (PCI, ...). > > > The target device type can be detected by reading the magic. > > > > > > Also, the macros RTE_DEVICE_DECL and RTE_DEVICE_PTR_DECL are introduced to > > > provide a generic way to declare a device or a pointer to a device. The macros > > > aim to preserve API backwards-compatibility. Eg. > > > > > > struct old_super_struct { => struct old_super_struct { > > > struct rte_pci_device *pci_dev; => RTE_DEVICE_PTR_DECL(pci_dev); > > > ... => ... > > > }; => }; > > > > > > struct old_super_struct inst; > > > > > > The new code should reference inst.dev.pci, the old code can still use the > > > inst.pci_dev. The previously introduced magic is included so one can ask the > > > instance about its type: > > > > > > if (inst.dev.magic == RTE_PCI_DEVICE_MAGIC) { > > > ... > > > } > > > > Rather than magic numbers i.e. #defines, an enum might be better. > > True. However, would it be helpful to put really some _magic_ numbers > there for debugging purposes (to clearly recognize the data type)? Or, > is it sufficient to just say 1 for PCI, 2 for SoC, 3 for xxx...? > I'd find it hard to see the need for actual magic numbers. I think the magic field should be renamed to "type" and the values taken from a device_type enum. Should make the code more readable e.g. if (inst.dev.type == RTE_DEVTYPE_PCI) { ... } /Bruce