From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) by dpdk.org (Postfix) with ESMTP id B8BEC2A66 for ; Mon, 4 Jul 2016 15:10:16 +0200 (CEST) Received: by mail-wm0-f41.google.com with SMTP id 187so21603076wmz.1 for ; Mon, 04 Jul 2016 06:10:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=n70kF+6zHsJ8CL2/Dq7McJEYwiBvK3qQrnQrJJTGhms=; b=RyTBXSlkru1SxoNvDBhL1R9NQS6QrSYmizmZdpOk4mfUEpPN0vUcGhCOtkrUBKkXPC Dc98aWxSSqKdqmZ0irIG3F24nf1nvW6ZeLwXreC9qWZe4/FLFqQmy78uK4tnM4LCDNWY GEEtBzKWSitry0CGRBMr4LHPjSn4I8D3M71DaGLOXMqj3HKMR4n79iibxHO+dK/lIIv8 LVrk2KN79NKqIKr9T/qcPRbDt/lj3MIje4y27eKMHOqSCOSstUTMpZHD92F4IT78pLjN jUOSx5ADAt3GlQjcrcktDBOfMiiipFFXmLsOLu07YYvyQMA+32yCwAu87IhTXS9f/H3a Ftkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=n70kF+6zHsJ8CL2/Dq7McJEYwiBvK3qQrnQrJJTGhms=; b=ZUR54CLCxQAMLccU5fMuZqRyy3Lghf1ijVyNPRYDFk2gdFq2rF6fu1lPT5LWx/NhRI q2QCESh2htZTIuQZdE2yJk7c6Kt7V1Gl1eFFpH/CYhPjLBXZO5naY0snf/WA78XCqyRp JArWsfwvAGtbyoyMjrGueWVZ8MJsj+vcKpiUd2mK2LXeDdJo4ZbMKwl3pZrz9CzB+QY/ UfPukUml7a5DQUz9TpRMTsQ0YC/Bc1RN+0PcOmj0HP2urLv4mVheICGJFga+tEF0SQUl xHR73wzrhkuuHHWg5DupALKtbtntvh6VfOduv8UHbYwas0gInbY5tRlDLdJ4JIjoi1ua ETeQ== X-Gm-Message-State: ALyK8tKzN/KUY7538rD1mHSoSGCaimz6mCa4TmSnSN7VrjrMcdf4IYqo1psIzo0hJIxY/1N8 X-Received: by 10.195.17.132 with SMTP id ge4mr4651544wjd.69.1467637816422; Mon, 04 Jul 2016 06:10:16 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id w81sm4826479wmg.20.2016.07.04.06.10.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Jul 2016 06:10:15 -0700 (PDT) From: Thomas Monjalon To: Neil Horman Cc: dev@dpdk.org, Panu Matilainen Date: Mon, 04 Jul 2016 15:10:14 +0200 Message-ID: <1880215.Z7Hk19TYxz@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20160704123414.GA5191@neilslaptop.think-freely.org> References: <1466189185-21952-1-git-send-email-nhorman@tuxdriver.com> <1467594845-3487-1-git-send-email-thomas.monjalon@6wind.com> <20160704123414.GA5191@neilslaptop.think-freely.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v9 0/7] export PMD infos 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: Mon, 04 Jul 2016 13:10:16 -0000 Hi Neil, I don't really understand why you don't accept I contribute to this patchset. More details below. 2016-07-04 08:34, Neil Horman: > On Mon, Jul 04, 2016 at 03:13:58AM +0200, Thomas Monjalon wrote: > > This is a respin of the series from Neil. > > It was planned to be integrated in 16.07-rc1 but the discovered issues > > make a new revision needed. > > There are still few things which could be improved but it is not mandatory > > to fix them for an integration in 16.07-rc2: > > - fix make clean after pmdinfogen > Clean works just fine, whats wrong with it? "make clean" do not remove the .pmd.* files. But it is not a blocking issue. > > - build installable pmdinfogen for target > Again, this seems to be working just fine for me, what do you see as wrong with > it? If we install the SDK as a binary package for another arch, we cannot use pmdinfogen as it is not cross-compiled (on purpose). It was just a thought for possible future enhancement and is not blocking. > > - convert pmdinfo.py to Python 3 > This was discussed weeks ago earlier in this thread, since there is no > requirement for python3 we decided not to use it. Why renege on that now? Yes we can take the script as is. It is just a note for future enhancement. Not blocking. > > - document dependency pyelftools > In what capacity beyond simply noting the fact that it imports that package? I don't know where we could document this dependency. Just a note, not blocking. > > Changes done in this v9: > > - fix build dependency of drivers on pmdinfogen > In what way is it broken? The drivers directory is dependent on building > pmdinfogen, what more do you want? The drivers directory Makefile is a rte.subdir.mk. It does not handle DEPDIRS. I've fix it in mk/rte.sdkbuild.mk drivers: | buildtools > > - fix build of mlx4, mlx5, aesni > They weren't broken as of V8, not sure what you're getting at here Yes they were because of typos. I guess you were not compiling them. > > - fix new drivers bnxt, thunderx, kasumi > > - fix MAINTAINERS file > > - fix coding style in pmdinfogen > > - add compiler checks for pmdinfogen > > - remove useless functions in pmdinfogen > > - fail build if pmdinfogen fails (set -e) > > - fix verbose pmdinfogen run > > - build pmdinfogen in buildtools directory (was app) > Are you kidding me!? We just went 10 rounds over where to build this stupid > application, and after I finally gave in to your demands, you change it one > last time and call it a fix? Thats a real slap in the face, thanks for that. We were discussing reusing hostapp.mk. And I was OK to use app/ as build directory. After checking sdkinstall.mk, I changed my mind to build in buildtools/. I do not call it a fix, just a change. Where do you see it is a fix? No slap. > > - install pmdinfogen in sdk package (was runtime) > > - fix CamelCase in pmdinfo.py > > - prefix executables with dpdk- > Again, seriously? Are you just trying to assert some sort of not invented here > mentality? We had this conversation over and over again weeks ago, but you > couldn't possibly chime in then? And you have to slip it in now, because this > is the way you want it, as though I did it wrong previously? You did not do it wrong. After more thoughts, I really think we must be careful to have a consistent namespace with tools we export publically. I'm thinking to re-use the dpdk- prefix for other tools. It's open to discussion as everything. > > - rename PMD_REGISTER_DRIVER -> RTE_REGISTER_DRIVER > Annnd...one more, of course. There simply no way you could leave this alone, > and modify subsequent pending patches to match the existing macro format, is > there? I'm just trying to have a consistent namespace: RTE_ in code, dpdk- for executables. > > - separate commit for hostapp.mk refresh > > - remove useless hostlib.mk > What does this have to do with 'fixes' for this series? It is not a fix, just a patch that I have added in the series. > > - spread doc in appropriate patches > > > Again, why? Whats wrong with adding documentation in its own patch? To modify > my work to fit your sensibilities and call it a fix is really quite an insult. It is neither a fix nor an insult. Having the doc and the code in the same patch helps to understand the patch. > Honestly, at this point, I'm done. Do what you want to it, I don't plan on > making any more changes. Please do not take it personnaly. I'm just trying to work on this interesting feature. Ideally you would have say "thank you for the work". At least it would be interesting to have your review.