[OE-core] [PATCH 1/1] linux-yocto 4.4: enable overlayfs by default

[Bruce Ashfield]

On Mon, Apr 4, 2016 at 10:48 PM, Robert Yang <liezhi.yang at windriver.com>
wrote:

>
>
> On 04/05/2016 10:31 AM, Bruce Ashfield wrote:
>
>>
>>
>> On Mon, Apr 4, 2016 at 9:53 PM, Robert Yang <liezhi.yang at windriver.com
>> <mailto:liezhi.yang at windriver.com>> wrote:
>>
>>
>>     Hi Bruce,
>>
>>     How many union fs on Linux, please? AFAIK:
>>     * unionfs: not supported by kernel any more.
>>     * aufs
>>     * overlayfs
>>
>>     If aufs and overlayfs are conflicted, how about:
>>
>>     KERNEL_UNION_FS ?= "features/overlayfs/overlayfs.scc"
>>
>>     KERNEL_EXTRA_FEATURES ?= "[snip] ${KERNEL_UNION_FS}"
>>
>>     I think that we really need a way to make iso/hddimg work by default
>>     to enhance the OOBE.
>>
>>
>> That sort of mechanism can work, but not if it is enabled by default. out
>> of box
>> experience
>> is one thing, but there are plenty of boot and image types that don't
>> need a
>> unionfs, and
>> we can't force these as =y for those image types.
>>
>> If we make a modular config, and a built-in config, we could pick the
>> modular
>> config by
>> default, and then have the package list for the images that need them,
>> rdepend
>> on the
>> appropriate modules.
>>
>
> Sounds good, so how about:
>
> 1) Update kernel to make overlayfs as module rather than builtin
>

Having two fragments make sense. one for built in, and one that is modules.
Since these are
distinct use case both sets of configuration are reasonable.


> 2) let core-image-minimal-initramfs RDEPENEDS on the module.
>
>
I'd still prefer that this be set in a distro or optional layer. Since why
should core image
minimal be the target for this ? There are any number of targets that might
be used for
live boot.

Bruce


> // Robert
>
>
>> Bruce
>>
>>
>>     // Robert
>>
>>     On 04/04/2016 07:56 AM, Bruce Ashfield wrote:
>>
>>
>>
>>         On Sun, Apr 3, 2016 at 5:46 PM, Richard Purdie
>>         <richard.purdie at linuxfoundation.org
>>         <mailto:richard.purdie at linuxfoundation.org>
>>         <mailto:richard.purdie at linuxfoundation.org
>>         <mailto:richard.purdie at linuxfoundation.org>>>
>>         wrote:
>>
>>              On Sun, 2016-04-03 at 06:11 -0400, Bruce Ashfield wrote:
>>              >
>>              >
>>              > On Sun, Apr 3, 2016 at 5:58 AM, Robert Yang <
>>              >liezhi.yang at windriver.com <mailto:liezhi.yang at windriver.com
>> >
>>         <mailto:liezhi.yang at windriver.com <mailto:
>> liezhi.yang at windriver.com>>>
>>
>>         wrote:
>>              > > So that iso can work well, otherwise the iso is readonly
>> and there
>>              > > would
>>              > > be errors. The other way is aufs, but overlayfs is more
>> pupolar and
>>              > > had
>>              > > been merged by kernel mainline, we need make iso work
>> well by
>>              > > default.
>>              > Nope. As I mentioned before, this can't be a always on
>> default. It
>>              > will conflict
>>              > with other unionFS use cases.
>>              >
>>              > If you want overlayfs enabled, it needs to be triggered
>> from a
>>              > specific image
>>              > or distro feature.
>>
>>              We can't change the kernel config from an image so it would
>> have to be
>>              a distro setting. Is there a problem with enabling both as
>> modules btw?
>>              I assume they can coexist?
>>
>>
>>         I've always found it limiting that we can't trigger kernel
>> features based on
>>         what an image'
>>         type actually needs, but I understand why/how it works like this.
>>
>>         If it can't be triggered by an image setting, then just keeping a
>> layer
>>         that is
>>         added
>>         to the build, that has a bbappend with the appropriate
>> KERNEL_FEATURES would
>>         also work, and is the approach that I've also taken.
>>
>>         Not that the existing configs are great in this respect (they
>> need a lot of
>>         streamlining),
>>         but building modules 'just in case' eventually leads to
>> allmodconfig :)
>>
>>         I'd imagine they could co-exist, but it isn't something I've
>> tried.
>>
>>         Bruce
>>
>>
>>              Cheers,
>>
>>              Richard
>>
>>
>>
>>
>>         --
>>         "Thou shalt not follow the NULL pointer, for chaos and madness
>> await
>>         thee at its
>>         end"
>>
>>
>>
>>
>> --
>> "Thou shalt not follow the NULL pointer, for chaos and madness await thee
>> at its
>> end"
>>
>


-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160405/930d6bb6/attachment-0002.html>