From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.chez-thomas.org (mail.mlbassoc.com [65.100.170.105]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 06192E0175F for ; Wed, 30 Oct 2013 07:43:53 -0700 (PDT) Received: by mail.chez-thomas.org (Postfix, from userid 1998) id 2D4B0F81214; Wed, 30 Oct 2013 08:43:53 -0600 (MDT) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hermes.chez-thomas.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=4.0 tests=ALL_TRUSTED,BAYES_00 autolearn=unavailable version=3.3.2 Received: from [192.168.1.114] (zeus [192.168.1.114]) by mail.chez-thomas.org (Postfix) with ESMTP id 41119F81212; Wed, 30 Oct 2013 08:43:52 -0600 (MDT) Message-ID: <52711B37.6050900@mlbassoc.com> Date: Wed, 30 Oct 2013 08:44:07 -0600 From: Gary Thomas User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Otavio Salvador References: <52710C89.7030903@mlbassoc.com> <527116CB.1050508@mlbassoc.com> In-Reply-To: Cc: "meta-freescale@yoctoproject.org" Subject: Re: [meta-fsl-arm-extra][PATCH] nitrogen6x.conf: Allow kernel provider override X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 14:43:54 -0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2013-10-30 08:33, Otavio Salvador wrote: > On Wed, Oct 30, 2013 at 12:25 PM, Gary Thomas wrote: >> On 2013-10-30 08:10, Otavio Salvador wrote: >>> >>> On Wed, Oct 30, 2013 at 11:41 AM, Gary Thomas wrote: >>>> >>>> This change lets the user override the choice of kernel in local.conf >>>> Without it, there is no way to build any kernel, e.g. linux-imx, other >>>> than the linux-boundary version. >>>> >>>> Signed-off-by: Gary Thomas >>> >>> >>> I really dislike this. >>> >>> I understand your need, and it is a valid one, but it'd be better you >>> to make a new machine (which includes this one) and override it there. >> >> Even if I did that (and I have), if I include this config file, I can >> never override this setting in a soft (user settable) way. > > Then you can force it in your machine. > >>> If we start allow all kind of override in machine configuration it >>> loses its meaning and complicates the support. >>> >>> Eric? comments? >>> >> >> Eric has already approved this change. > > This is not up to me but I'd like to discuss it a little bit further > before merging it... > > My main concern about this is the support. As I said it is a valid > use-case but /most/ people will end with a .conf for the custom > settings in the end with their internal fork or so. Do it in > local.conf or environment is not advised as it is easy to be forgotten > or do wrong so for every product it is better to have a .conf in case > it needs specific kernel/u-boot patches. > A reasonable concern. I do note that having this be soft in .conf seems to be common practice in the rest of the Yocto world. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------