From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id B970DE0175F for ; Wed, 30 Oct 2013 07:42:11 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id r10so1053676pdi.18 for ; Wed, 30 Oct 2013 07:42:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=tjBTGb1A/ipaiWZwpDuuct+8O9i5AiAJPk1wgloQPk8=; b=hEGfF5k0Hv7V0SfviMgycgkryerbtcDuTso9p593vN7nFajTrlJEcGrXQr9Tgc+TXw aZl1rQ3rOePMWEOAFLqQpIonVu3sob+eJbpzWCc6EOgaOv7OvJK8CMgMG+HarOocyYhk IHO9cBOkEJIjsluOTqDReNXAaGu0Tq5qYHLtt3dH5rt+636LorNSQJshBzpJqOznZzHO t6njb23yD+1LnmVq6b28kvF5wIx1f6KVKrkCbHlZ7+T4xHkAbYlPzBG3+6GVqSmBSliB gQk8MgaPYvvTcJLVQMBb43/EhDqqSds+3CEy4AtAmKVGKigdVdSkEMKC/LHNVF87KYsC H+XA== X-Gm-Message-State: ALoCoQl1IP8XicOtC9NMOgj8hBru5vW0hEaoNCCVTqMUsZfmKlpxQ+f3N6nBR4nrKW2tRw9msjTT X-Received: by 10.68.212.165 with SMTP id nl5mr2242199pbc.191.1383144131049; Wed, 30 Oct 2013 07:42:11 -0700 (PDT) Received: from [192.168.1.8] (ip98-167-230-131.ph.ph.cox.net. [98.167.230.131]) by mx.google.com with ESMTPSA id de1sm41848898pbc.7.2013.10.30.07.42.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Oct 2013 07:42:10 -0700 (PDT) Message-ID: <52711ABF.5050308@boundarydevices.com> Date: Wed, 30 Oct 2013 07:42:07 -0700 From: Eric Nelson 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> <527116BE.7030303@boundarydevices.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:42:11 -0000 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Otavio, On 10/30/2013 07:28 AM, Otavio Salvador wrote: > Hello Eric, > > On Wed, Oct 30, 2013 at 12:25 PM, Eric Nelson > wrote: >> On 10/30/2013 07:10 AM, 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. >>> >> >> I'm not sure I understand why. It seems perfectly reasonable to me >> to build a new kernel recipe and use it, while retaining other >> information from the machine configuration. >> >> I'm thinking specifically of a user who may have a custom kernel >> tree with pin-muxing based on their usage. > > I see the point and I do have this case internally here; the point is > if we have it 'soft' and someone reports: > > Nitrogen6X is not working. Next question needs to be, are you using > linux-boundary or another? > I understand your point, but it's going to happen anyway. The beauty (and curse) of flexible hardware is that it's flexible ;) I think the best we can hope for in terms of support is to always ask if a failure occurs with a "stock" build... Fresh "repo sync", specified U-Boot, et cetera. I don't know if hard-coding this value will meaningfully change things. >>> If we start allow all kind of override in machine configuration it >>> loses its meaning and complicates the support. >>> >>> Eric? comments? >>> >> >> I'm not sure I understand the concern. This seems pretty >> straightforward. The default is there, but a user can >> over-ride it. > > If user forks the kernel, adding a machine .conf file is the easiest > part of it. I'd to avoid support uncertainty regarding settings. > That's true, too (machine configurations aren't very complicated), but my understanding of that is recent. Regards, Eric