From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH 4/5] eal: add an error code to plugin init for the next step Date: Wed, 21 Oct 2015 10:14:18 +0200 Message-ID: <1963689.ejoAfUUbUG@xps13> References: <5620F824.4000707@redhat.com> <5620FDDE.3090100@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org To: Panu Matilainen Return-path: Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by dpdk.org (Postfix) with ESMTP id 74873924B for ; Wed, 21 Oct 2015 10:15:23 +0200 (CEST) Received: by wikq8 with SMTP id q8so81337088wik.1 for ; Wed, 21 Oct 2015 01:15:23 -0700 (PDT) In-Reply-To: <5620FDDE.3090100@redhat.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 2015-10-16 16:38, Panu Matilainen: > On 10/16/2015 04:14 PM, Panu Matilainen wrote: > > On 10/16/2015 03:59 PM, Bruce Richardson wrote: > >> On Fri, Oct 16, 2015 at 02:58:16PM +0300, Panu Matilainen wrote: > >>> Signed-off-by: Panu Matilainen > >>> --- > >>> lib/librte_eal/bsdapp/eal/eal.c | 3 ++- > >>> lib/librte_eal/common/eal_common_options.c | 3 ++- > >>> lib/librte_eal/common/eal_options.h | 2 +- > >>> lib/librte_eal/linuxapp/eal/eal.c | 3 ++- > >>> 4 files changed, 7 insertions(+), 4 deletions(-) > >> > >> Again, another minor nit, but couldn't this be done when refactoring > >> in previous > >> patches, rather than needed a whole separate commit ? > > > > Of course it'd be possible to do this earlier, I pondered about it too > > but then went with this because > > a) otherwise I would've had to rework the earlier patches again > > b) not knowing which way people prefer it, I might've had to rework it > > back to the original > > c) didn't know we were saving commits > > d) doing it like this maintains a certain symmetry to how stuff is > > introduced > > In other words: I spent many years working with a codebase where the > policy was to never change code while moving it around otherwise. So > yeah, matter of policy, taste and all, I'm clearly still learning where > the fine line is in case of dpdk :) > > The series can easily be shrunken into two logical steps if that's > preferred: > 1) move the plugin handling code to common > 2) add the plugin directory support Yes, looks good. Thanks