From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v3 5/9] pmdinfogen: move to drivers subdirectory Date: Wed, 21 Jun 2017 14:14:33 +0200 Message-ID: <2497445.pUfxcqGo6k@xps> References: <10937675.k8W90Yh6uJ@xps> <20170621113929.GE2344@bidouze.vm.6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: dev@dpdk.org To: =?ISO-8859-1?Q?Ga=EBtan?= Rivet Return-path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 9C6CF374 for ; Wed, 21 Jun 2017 14:14:34 +0200 (CEST) In-Reply-To: <20170621113929.GE2344@bidouze.vm.6wind.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 21/06/2017 13:39, Ga=EBtan Rivet: > On Wed, Jun 21, 2017 at 12:00:24PM +0200, Thomas Monjalon wrote: > > 21/06/2017 11:40, Ga=EBtan Rivet: > > > On Wed, Jun 21, 2017 at 09:57:18AM +0200, Thomas Monjalon wrote: > > > > Another (probably better) solution is to keep basic definitions > > > > and helpers in EAL: > > > > - rte_pci.h keeps only some PCI definitions and helpers > > > > like rte_pci_addr and eal_parse_pci_BDF() in EAL > > > > - bus management is done in the PCI driver > > > >=20 > > > > For pmdinfogen, we just need struct rte_pci_id. > > > > Other tools or applications will probably need this kind of basic > > > > struct and functions available in EAL. > > >=20 > > > I mostly agree, this proposal should be kept to a minimum at first for > > > this release and carefully expanded afterward. > > >=20 > > > If that's ok, I will propose a new version of this patchset with a new > > > librte_pci, that might fix both pmdinfogen and librte_kni. > >=20 > > Why creating a new librte_pci instead of just keeping it in EAL? >=20 > While I agree that it makes sense to have PCI helpers shared among > several subsystems, I do not see a reason for the EAL to rely on it. >=20 > The EAL is the bedrock of the whole system. Having those helpers within > would mean that one expects them to be used to build this bedrock. It > would be misleading. >=20 > In the context of a framework, aimed at being used by others, an okay > architecture is one that works. A good architecture is one that > intrinsically convey meaning and explains its goal to developers relying > on it. I think that having this PCI lib within EAL just because nothing > prevents us from doing so is mistaken, in this regard. >=20 > Conversely, the argument about being conservative in the changes, > especially to an essential part such as the EAL, is obsolete for this > release and this subsystem, as deep changes are necessary anyway, > and the design should be right from the get go to allow further stability. >=20 > Finally, the PCI lib and bus is also an example for other developers. I > do not think that all other hardware buses should be allowed in adding > their own specific helpers to the EAL. In this regard, there is no > reason to have an exception made just for the PCI lib. You get a point :)