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
2) let core-image-minimal-initramfs RDEPENEDS on the module.
// 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"
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
