On Mon, Apr 4, 2016 at 10:48 PM, Robert Yang <[email protected]> wrote:
> > > On 04/05/2016 10:31 AM, Bruce Ashfield wrote: > >> >> >> On Mon, Apr 4, 2016 at 9:53 PM, Robert Yang <[email protected] >> <mailto:[email protected]>> 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 >> <[email protected] >> <mailto:[email protected]> >> <mailto:[email protected] >> <mailto:[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] <mailto:[email protected] >> > >> <mailto:[email protected] <mailto: >> [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" >> >> >> >> >> -- >> "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"
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
