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

[Bruce Ashfield]

On Mon, Apr 4, 2016 at 9:53 PM, Robert Yang <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.

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>>
>> 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>> 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"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160404/68655c48/attachment-0002.html>