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

[Bruce Ashfield]

On Sun, Apr 3, 2016 at 5:46 PM, Richard Purdie <
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> 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"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160403/d3a4b2ed/attachment-0002.html>