[dpdk-dev] [PATCH 4/5] eal: add an error code to plugin init for the next step

Thomas Monjalon thomas.monjalon at 6wind.com
Wed Oct 21 10:14:18 CEST 2015


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 <pmatilai at redhat.com>
> >>> ---
> >>>   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


More information about the dev mailing list