All of lore.kernel.org
 help / color / mirror / Atom feed
From: Darren Hart <dvhart@linux.intel.com>
To: Tom Rini <tom.rini@gmail.com>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: Consistency and use cases for IMAGE_FSTYPES
Date: Fri, 23 Mar 2012 09:34:02 -0700	[thread overview]
Message-ID: <4F6CA5FA.8020605@linux.intel.com> (raw)
In-Reply-To: <20120323162900.GD9551@bill-the-cat>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 03/23/2012 09:29 AM, Tom Rini wrote:
> On Fri, Mar 23, 2012 at 09:17:20AM -0700, Darren Hart wrote:
>> On 03/23/2012 08:48 AM, Tom Rini wrote:
>>> On Fri, Mar 23, 2012 at 01:14:24AM +0000, Richard Purdie
>>> wrote:
>>>> On Thu, 2012-03-22 at 19:53 -0400, Denys Dmytriyenko wrote:
>>>>> On Thu, Mar 22, 2012 at 11:26:24PM +0000, Richard Purdie
>>>>> wrote:
>>>>>> On Fri, 2012-03-09 at 14:39 -0700, Tom Rini wrote:
>>>>>>> Hey all,
>>>>>>> 
>>>>>>> Over in meta-ti I kicked off a discussion 
>>>>>>> (https://lists.yoctoproject.org/pipermail/meta-ti/2012-March/000779.html)
>>>>>>>
>>>>>>> 
about if we should be using '?=' or '+=' with IMAGE_FSTYPES in the
>>>>>>> machine conf files.  This has been discussed a little
>>>>>>> bit before 
>>>>>>> (http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/2060/focus=2061).
>>>>>>>
>>>>>>> 
The problem is we have the following and I believe ultimately
>>>>>>> conflicting use cases:
>>>>>> 
>>>>>> I've been under the impression that we decided upon:
>>>>>> 
>>>>>>> - The machine needs to say 'I need or support the
>>>>>>> following formats'
>>>>>> 
>>>>>> so the machine starts and sets:
>>>>>> 
>>>>>> IMAGE_FSTYPES = "xxxx"
>>>>>> 
>>>>>>> - The distro needs to say 'I always want format X'
>>>>>> 
>>>>>> so the distro can do:
>>>>>> 
>>>>>> IMAGE_FSTYPES += " yyy"
>>>>>> 
>>>>>>> - The user needs to say 'I know best, give me only
>>>>>>> format X'
>>>>>> 
>>>>>> So the user can do:
>>>>>> 
>>>>>> IMAGE_FSTYPES = "X"
>>>>> 
>>>>> Since local.conf gets parsed before machine.conf and
>>>>> distro.conf, the user needs to do this override:
>>>>> 
>>>>> IMAGE_FSTYPES_local = "X"
>>>>> 
>>>>> Otherwise machine.conf will always overwrite it with "xxxx"
>>>>> with its unconditional assignment.
>>>> 
>>>> Right, I'd forgotten that little detail :/.
>>>> 
>>>> It actually makes me wonder if our include order is the right
>>>> one but now isn't the time to try changing that.
>>>> 
>>>> I agree the neatest way to change it is probably something
>>>> like MACHINE_FSTYPES. I do worry a lot about backwards
>>>> compatibility though and I'd also point out where we're at in
>>>> the release cycle (bug fix only).
>>> 
>>> Well, one problem that would make this a bugfix is that no one
>>> does what you say we agreed on today.  oe-core has qemu.inc
>>> using ?=, meta-intel is using += and meta-ti is mixed (which is
>>> what got this started).
>>> 
>>> 
>> 
>> Is this causing any nasty failures right now, or is it in the
>> "this is a confusing mess and it would be nice to get it cleaned
>> up" bucket? If the latter, I think I'd prefer to wait a bit an
>> clean up the local.conf/machine.conf IMAGE_FSTYPES clobbering
>> issue.
> 
> Well, I found this as part of adding UBI support for a board and
> it wasn't sticking.
> 
> I'd go so far as to say that for a release, we really need to pick
> a standard, document and follow it.  If it's machine.conf does =,
> everyone else does += and user's have to do _local =, fine, it
> sucks but it's documented and consistent on all of the BSP layers.
> 
>> If this isn't really fixable (for whatever requirements bitbake
>> has on load/parse order of config files), then Koen's
>> EXTRA_IMAGE_FSTYPES seems like the most consistent mechanism with
>> other things, like CORE_IMAGE_EXTRA_INSTALL (OK, maybe
>> IMAGE_EXTRA_FSTYPES ?).
>> 
>> So the default becomes:
>> 
>> IMAGE_FSTYPES ?= ${IMAGE_EXTRA_FSTYPES}
>> 
>> and DISTROs might define that as:
>> 
>> IMAGE_FSTYPES += "yyy"
>> 
>> and users can update local.conf to be:
>> 
>> IMAGE_FSTYPES = "X"
>> 
>> But, doesn't this meant the DISTRO append will still change the 
>> IMAGE_FSTYPES to "X yyy" even though the user intended "only X"?
> 
> How about: bitbake.conf: IMAGE_FSTYPES ??= ${IMAGE_EXTRA_FSTYPES} 
> distro.conf: IMAGE_FSTYPES ?= "yyy ${IMAGE_EXTRA_FSTYPES}" 
> local.conf: IMAGE_FSTYPES = "X"
> 
> Or am I forgetting the magic of ??= again...
> 

What would machine.conf do in this scenario?

IMAGE_FSTYPES_append_machine = "Z" ?

or

IMAGE_EXTRA_FSTYPES = "Z"

- -- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPbKXvAAoJEKbMaAwKp364kN8IAKygG06LhMH7FI6E4L0xuX/U
i6szfRYOX2mWz6OAf/pPJtyvDjtwpgpLvRQEpOfIIVPciOlw/aTCZW9kGRG6hQtl
UxnNfyp25tqc7IFTm5AXVRvfMGlI+V7tXoPK117i/EXyuRQbPood5QUN6YUR+NXF
Bw0gxhYr/JSZtKiBCIRRbO7o5SSGpcDydOkG7RIsA3XS2dT5YzuGfFWTKbYyAct/
g97aqvxXxL3h+/kr5rJ9dR+qYjCsmkyqT6ePDzXlkzQEoQUHs+7u+u0Au8Sg+Sxg
W53G3MoOlzSjLojhTlTYfzuwxfEv7Jkg0q6hYOGUSlGPQ5Fuc8UfAiSi5MAQVL0=
=92cW
-----END PGP SIGNATURE-----



  reply	other threads:[~2012-03-23 16:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-09 21:39 Consistency and use cases for IMAGE_FSTYPES Tom Rini
2012-03-10  6:29 ` Koen Kooi
2012-03-12 20:25   ` Denys Dmytriyenko
2012-03-22 21:40     ` Tom Rini
2012-03-22 23:26 ` Richard Purdie
2012-03-22 23:53   ` Denys Dmytriyenko
2012-03-23  1:14     ` Richard Purdie
2012-03-23 15:48       ` Tom Rini
2012-03-23 16:17         ` Darren Hart
2012-03-23 16:29           ` Tom Rini
2012-03-23 16:34             ` Darren Hart [this message]
2012-03-23 17:03               ` Tom Rini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F6CA5FA.8020605@linux.intel.com \
    --to=dvhart@linux.intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=tom.rini@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.