From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gaetan.rivet@6wind.com> Received: from mail-wr0-f169.google.com (mail-wr0-f169.google.com [209.85.128.169]) by dpdk.org (Postfix) with ESMTP id A59BA7CBF for <dev@dpdk.org>; Wed, 21 Jun 2017 17:15:00 +0200 (CEST) Received: by mail-wr0-f169.google.com with SMTP id c11so83686034wrc.3 for <dev@dpdk.org>; Wed, 21 Jun 2017 08:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=co3X60abyNdlYxtdd3LlJvtSbomPTmYRHDmcN2DqLoo=; b=tWSxi5PR6+gkLEQT2UurkFPs+HJF6epYWIDda8Lv4Mg2UYMKOxkKiPRTzuUZwq/gnJ 1mHDQpi2W3cDBTWsGaZmIv0YlafZD2FIPsIksD/OCEEkJZmLzxY+n9oDjeJ57g4W/OMW /Bk+bX/IXLt/Wm6ndAF0Mm5BGXW555/8z8f3t5cif+xGBlZsb4Z5RMKyoeLo+vbmuoJJ EHHlyEU/wsHMM3yko+x586vlz5UnkntH20Q+LjTphsb9AOPh/6R7vomtOcZD25fx1wsn To7WdDpIzwCRw+nYzqrlYICfKLkPt6Xv1+PAi6YSmSKnpot5b4PQ0Evi2efb3vMBYSay g0FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=co3X60abyNdlYxtdd3LlJvtSbomPTmYRHDmcN2DqLoo=; b=d33xlEs1PRDkXn2xM2xhDOf6lccdMnFodcgKTguxg3z/4hev/B22gcndC39iZyckjq yY9oD0zA6usX9EjXtvXVGM7E5QfJpScccYWjcJIrJStuFSmhdvG4OIlcpvyFTDSyUef5 mAf1znSg4cj1dShCVfh0z70v9uD4iXwAgXV1Cs8vdZQroqahG+PwJ64g+8cjoWl/HUni hwR72kYrL1Jfv7xuzRgYyeZB6sm47O63ShU0fy5iNvIyysLXRMeoLr+VH/PL7x4pRa39 YhmvVlYTuxJJPrR3WPgY7oCbZtg2m8BY8uPTCQW3To+gOEcWH5hwvGyLN7geofff8iAz GIkw== X-Gm-Message-State: AKS2vOx7yhcii/HdEc+dIN+a+cEv3hnMIy3G9v8SBZ9hcVM3wozDcUaT 4BZNK69SY0nV+VYvMvk= X-Received: by 10.223.171.69 with SMTP id r5mr631161wrc.57.1498058100225; Wed, 21 Jun 2017 08:15:00 -0700 (PDT) Received: from bidouze.vm.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id g20sm7926673wmd.2.2017.06.21.08.14.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jun 2017 08:14:59 -0700 (PDT) Date: Wed, 21 Jun 2017 17:14:51 +0200 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet <gaetan.rivet@6wind.com> To: "Wiles, Keith" <keith.wiles@intel.com> Cc: "Richardson, Bruce" <bruce.richardson@intel.com>, Thomas Monjalon <thomas@monjalon.net>, "dev@dpdk.org" <dev@dpdk.org> Message-ID: <20170621151451.GG2344@bidouze.vm.6wind.com> References: <20170620212139.9508-1-thomas@monjalon.net> <20170621102702.GA93468@bricha3-MOBL3.ger.corp.intel.com> <2D791B20-6CAC-482D-811B-4B4829242710@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2D791B20-6CAC-482D-811B-4B4829242710@intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [RFC PATCH] mk: symlink every headers first X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Wed, 21 Jun 2017 15:15:00 -0000 Hi, On Wed, Jun 21, 2017 at 02:27:49PM +0000, Wiles, Keith wrote: > > > On Jun 21, 2017, at 5:27 AM, Bruce Richardson <bruce.richardson@intel.com> wrote: > > > > On Tue, Jun 20, 2017 at 11:21:39PM +0200, Thomas Monjalon wrote: > >> If a library or a build tool uses a definition from a driver, > >> there is a build ordering issue, like seen when moving PCI code > >> into a bus driver. > >> > >> One option is to keep PCI helpers and some common definitions in EAL. > >> The other option is to symlink every headers at the beginning of > >> the build so they can be included by any other component. > >> > >> This patch shows how to achieve the second option. > >> > >> Signed-off-by: Thomas Monjalon <thomas@monjalon.net> > >> --- > > > > My 2c. > > > > This may be worth doing, however, two points to consider. > > > > 1. If we look to change build system this may not be worth doing unless > > a compelling need becomes obvious in the short term. In the meantime, > > for cases where it is needed... > > 2. libraries can already access the includes from drivers or other > > places fairly easily, just by adding the relevant "-I" flag to the > > CFLAGS for that lib. > > > > That said, since the work is already done developing this, and if it > > doesn't hurt in terms of build time, I suppose we might as well merge > > it in. > > > > So tentative ack from me, subject to testing and feedback from others. > > +1, I already have to make sure everything is symlinked first in my private DPDK work for other reasons. This patch would allow me to remove that special code. > > > > > /Bruce > > Regards, > Keith > Personally I do not like this approach. A well designed architecture introduces constraints that developers ought to follow. These constraints, when well defined, foster a cleaner growth on top of it with better practices. This solution is a crutch meant to alleviate other deep-rooted issues that should be fixed anyway. It makes them disappear right now, only for them to reappear when people will write libs and drivers with blurred hierarchies and hard-to-determine dependencies. These constraints should be a tool for developers to be critical of their work and help them see whether they are making a mistake, for example by putting implementation specific data in generic structures (as seen by the problems at the root of this RFC: KNI, pmdinfogen dependencies). This would have led for example eventdev, cryptodev, ethdev to leave PCI specific data within their structures. Yes, it works. But it is not clean, it leads to ABI instability, unsafe design practices. This RFC is the easy way out, making it work, at the price of technical debt. I understand that it is a lot of work to properly clean up the structures and that ressource is scarce. Having a clear architecture and proper structures however helps external eyes to read, understand, use, and ultimately contribute. This kind of move goes against the previous work that was done to make devices, drivers and buses generic, which I think was right. I do not feel that it is my place to nack, nor that it is constructive to block this if others are thinking that it is useful; however I hope to sway others to my position. Cheers, -- Gaëtan Rivet 6WIND