From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas.monjalon@6wind.com>
Subject: Re: [PATCH v3 2/2] config: disable
	CONFIG_RTE_SCHED_VECTOR for arm
Date: Mon, 30 Nov 2015 14:59:45 +0100
Message-ID: <14937680.5CmUUClIOq@xps13>
References: <1448631268-10692-1-git-send-email-jerin.jacob@caviumnetworks.com>
 <20151130185544.GA6141@qq.com>
 <20151130142706.5b24b39d@pcviktorin.fit.vutbr.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: dev@dpdk.org
To: Jan Viktorin <viktorin@rehivetech.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45])
 by dpdk.org (Postfix) with ESMTP id 539DD2C72
 for <dev@dpdk.org>; Mon, 30 Nov 2015 15:00:53 +0100 (CET)
Received: by wmvv187 with SMTP id v187so158094424wmv.1
 for <dev@dpdk.org>; Mon, 30 Nov 2015 06:00:53 -0800 (PST)
In-Reply-To: <20151130142706.5b24b39d@pcviktorin.fit.vutbr.cz>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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).
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.
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.