<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 4, 2016 at 9:53 PM, Robert Yang <span dir="ltr"><<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi Bruce,<br>
<br>
How many union fs on Linux, please? AFAIK:<br>
* unionfs: not supported by kernel any more.<br>
* aufs<br>
* overlayfs<br>
<br>
If aufs and overlayfs are conflicted, how about:<br>
<br>
KERNEL_UNION_FS ?= "features/overlayfs/overlayfs.scc"<br>
<br>
KERNEL_EXTRA_FEATURES ?= "[snip] ${KERNEL_UNION_FS}"<br>
<br>
I think that we really need a way to make iso/hddimg work by default<br>
to enhance the OOBE.<br></blockquote><div><br></div><div>That sort of mechanism can work, but not if it is enabled by default. out of box experience<br></div><div>is one thing, but there are plenty of boot and image types that don't need a unionfs, and<br></div><div>we can't force these as =y for those image types.<br><br></div><div>If we make a modular config, and a built-in config, we could pick the modular config by<br></div><div>default, and then have the package list for the images that need them, rdepend on the<br></div><div>appropriate modules.<br><br></div><div>Bruce<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
// Robert<span class=""><br>
<br>
On 04/04/2016 07:56 AM, Bruce Ashfield wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<br>
On Sun, Apr 3, 2016 at 5:46 PM, Richard Purdie<br></span>
<<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a> <mailto:<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>>><span class=""><br>
wrote:<br>
<br>
On Sun, 2016-04-03 at 06:11 -0400, Bruce Ashfield wrote:<br>
><br>
><br>
> On Sun, Apr 3, 2016 at 5:58 AM, Robert Yang <<br></span><div><div class="h5">
><a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a> <mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a>>> wrote:<br>
> > So that iso can work well, otherwise the iso is readonly and there<br>
> > would<br>
> > be errors. The other way is aufs, but overlayfs is more pupolar and<br>
> > had<br>
> > been merged by kernel mainline, we need make iso work well by<br>
> > default.<br>
> Nope. As I mentioned before, this can't be a always on default. It<br>
> will conflict<br>
> with other unionFS use cases.<br>
><br>
> If you want overlayfs enabled, it needs to be triggered from a<br>
> specific image<br>
> or distro feature.<br>
<br>
We can't change the kernel config from an image so it would have to be<br>
a distro setting. Is there a problem with enabling both as modules btw?<br>
I assume they can coexist?<br>
<br>
<br>
I've always found it limiting that we can't trigger kernel features based on<br>
what an image'<br>
type actually needs, but I understand why/how it works like this.<br>
<br>
If it can't be triggered by an image setting, then just keeping a layer that is<br>
added<br>
to the build, that has a bbappend with the appropriate KERNEL_FEATURES would<br>
also work, and is the approach that I've also taken.<br>
<br>
Not that the existing configs are great in this respect (they need a lot of<br>
streamlining),<br>
but building modules 'just in case' eventually leads to allmodconfig :)<br>
<br>
I'd imagine they could co-exist, but it isn't something I've tried.<br>
<br>
Bruce<br>
<br>
<br>
Cheers,<br>
<br>
Richard<br>
<br>
<br>
<br>
<br>
--<br>
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its<br>
end"<br>
</div></div></blockquote>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"</div>
</div></div>