From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) by dpdk.org (Postfix) with ESMTP id 0527A58DB for ; Mon, 30 Nov 2015 15:15:01 +0100 (CET) Received: by wmuu63 with SMTP id u63so131264481wmu.0 for ; Mon, 30 Nov 2015 06:15:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=GEwTixNfTA3x/xBGvPKCrp8zK6U3dNmcvHz9J4Fnaz0=; b=yQSIl6iV3ufqNf5xPMJnkWsWf228ow0CIm2jtbPE7lkTik2a2VPLXKv9u724mocW85 S+He8TNTVZXMwBLYOcx2ZioHcgdpnIEaG9+g9mvjH0U+B/1TtKsmXjHNBOJy/orz5ZOl KTiZBvO+t74mrAUYNQofK/CHP8TRGTkqZ0R+JD/Az4M+hDWlw2zEAi8hfdJw0+TBfuGl KAKfiW21BFMpAVUs45uE+ujhkmxtHBC4zU4OSCqZLruIbdD4LA4/OomlZZx8+r1sa8l5 evCuCeWcjWkBgmAx8db8lPCq4/gmveob0bMgo/JzlIqciS5cheUaK+BdQaKhXM0dynXq 2CaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=GEwTixNfTA3x/xBGvPKCrp8zK6U3dNmcvHz9J4Fnaz0=; b=GagRikd7uG2oUF4BHhGZYhbOhhJpRxqVGLzMs7+Rl//TEV0og///oLGbBY5bhx8Hzh 5iLfzfSklyAzQmZvoF+kj/50JYWSJW7aVsHpIdBHVaQlGIQ/0DPIxj0v2614kxm6Nm+r W7DJ1PyWVLjM1OaEjixchkF3ZAettZqUgUZDC0mYdwj20+85ZrQ4QtA6xIafw+PkUv4g p96EJImGtl820JBDzc7x8r9yYrhxPq0ku6HGJwQd29w2U4X67akQV2yTOfr0FioNwprg ZVuBbUlm6dtdAYZAHPjGQpRCtzq6XqwAEobyMAg15K03wQ9iUQFyWjEZ/1zD7MAg5KbV PDSA== X-Gm-Message-State: ALoCoQn3mg5SQ4JfjZtdRojjFTEc3J4H1yMKntg4g3FHGr0l1R8m23gYYlZd31XHYf/wfSFXszpG X-Received: by 10.28.175.135 with SMTP id y129mr29466190wme.24.1448892900758; Mon, 30 Nov 2015 06:15:00 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by smtp.gmail.com with ESMTPSA id bh6sm35936911wjb.0.2015.11.30.06.15.00 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Nov 2015 06:15:00 -0800 (PST) From: Thomas Monjalon To: Jan Viktorin Date: Mon, 30 Nov 2015 15:13:53 +0100 Message-ID: <3362350.VxlxT3kjya@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20151130150421.43d50e59@pcviktorin.fit.vutbr.cz> References: <1448631268-10692-1-git-send-email-jerin.jacob@caviumnetworks.com> <14937680.5CmUUClIOq@xps13> <20151130150421.43d50e59@pcviktorin.fit.vutbr.cz> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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:15:01 -0000 2015-11-30 15:04, Jan Viktorin: > 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?) Please take your time. We will better ready to discuss it when the "make install" issue will be solved. > > 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... I'm not speaking about complexity here, but just features. With kconfig, options and dependencies are well described but the defaults are fixed. With a script, you can have some dynamically generated defaults. Please expose the needs and features clearly in another thread. Thanks