From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wes1-so2.wedos.net (wes1-so2.wedos.net [46.28.106.16]) by dpdk.org (Postfix) with ESMTP id 0C43F58DB for ; Mon, 30 Nov 2015 15:07:01 +0100 (CET) Received: from pcviktorin.fit.vutbr.cz (pcviktorin.fit.vutbr.cz [147.229.13.147]) by wes1-so2.wedos.net (Postfix) with ESMTPSA id 3p8Szm4lgTzqZ; Mon, 30 Nov 2015 15:07:00 +0100 (CET) Date: Mon, 30 Nov 2015 15:04:21 +0100 From: Jan Viktorin To: Thomas Monjalon Message-ID: <20151130150421.43d50e59@pcviktorin.fit.vutbr.cz> In-Reply-To: <14937680.5CmUUClIOq@xps13> References: <1448631268-10692-1-git-send-email-jerin.jacob@caviumnetworks.com> <20151130185544.GA6141@qq.com> <20151130142706.5b24b39d@pcviktorin.fit.vutbr.cz> <14937680.5CmUUClIOq@xps13> Organization: RehiveTech MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v3 2/2] config: disable CONFIG_RTE_SCHED_VECTOR for arm 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, 30 Nov 2015 14:07:01 -0000 On Mon, 30 Nov 2015 14:59:45 +0100 Thomas Monjalon wrote: > 2015-11-30 14:27, Jan Viktorin: > > I believe (and have already expressed this idea) that this is not a > > problem of architecture ports but it is a problem of the build system. > > Love me or hate me, in my opinion the build system is broken :). The > > build system should be able to solve this. > > > > I've created privately an integration of kconfig into DPDK, however, it > > is far from being usable and I did not have time to make at least an > > RFC patch. If there is an attitude in the community to include such > > thing in the future versions, I'd like to make some more effort in this > > area. > > If we were integrating kconfig, we should consider kconfig-frontends > (http://ymorin.is-a-geek.org/projects/kconfig-frontends). True, this seems to be the easiest way. I've already used it successfully. > But I'm not sure it is the way to go. You are welcome to open the debate > in a dedicated thread by explaining the benefits compared to a configuration > script. OK. I will consider this. Probably, after the community call... (Or before?) > I think most of the options could be automatically guessed given the target > CPU, kernel, libc and compiler. It looks like a scripting task, not a > manual configuration (as kconfig provides). But maybe we can mix kconfig > and some automatic defaults. > Well, scripting... If you have issues like "feature X" does not work on "platform A" then you need to express this. If you try to script such dependency, I am afraid you always end up with a system of the same or equivalent complexity as the kconfig already has :). We'll see... Regards Jan -- Jan Viktorin E-mail: Viktorin@RehiveTech.com System Architect Web: www.RehiveTech.com RehiveTech Brno, Czech Republic