On Sun, Apr 3, 2016 at 5:46 PM, Richard Purdie < [email protected]> wrote:
> On Sun, 2016-04-03 at 06:11 -0400, Bruce Ashfield wrote: > > > > > > On Sun, Apr 3, 2016 at 5:58 AM, Robert Yang < > > [email protected]> 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"
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
