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.
// 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]>>
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]>> 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
