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
