<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 5, 2016 at 2:42 AM, 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"><span class=""><br>
<br>
On 04/05/2016 02:33 PM, 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 Mon, Apr 4, 2016 at 10:48 PM, Robert Yang <<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a><br></span><span class="">
<mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a>>> wrote:<br>
<br>
<br>
<br>
On 04/05/2016 10:31 AM, Bruce Ashfield wrote:<br>
<br>
<br>
<br>
On Mon, Apr 4, 2016 at 9:53 PM, Robert Yang <<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a><br>
<mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a>><br></span><span class="">
<mailto:<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>>>><br>
wrote:<br>
<br>
<br></span><div><div class="h5">
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>
<br>
<br>
That sort of mechanism can work, but not if it is enabled by default.<br>
out of box<br>
experience<br>
is one thing, but there are plenty of boot and image types that don't need a<br>
unionfs, and<br>
we can't force these as =y for those image types.<br>
<br>
If we make a modular config, and a built-in config, we could pick the<br>
modular<br>
config by<br>
default, and then have the package list for the images that need them,<br>
rdepend<br>
on the<br>
appropriate modules.<br>
<br>
<br>
Sounds good, so how about:<br>
<br>
1) Update kernel to make overlayfs as module rather than builtin<br>
<br>
<br>
Having two fragments make sense. one for built in, and one that is modules.<br>
Since these are<br>
distinct use case both sets of configuration are reasonable.<br>
</div></div></blockquote>
<br>
How about this:<br>
<br>
diff --git a/ktypes/preempt-rt/preempt-rt.cfg b/ktypes/preempt-rt/preempt-rt.cfg<br>
index 4c62804..28ad8cf 100644<br>
--- a/ktypes/preempt-rt/preempt-rt.cfg<br>
+++ b/ktypes/preempt-rt/preempt-rt.cfg<br>
@@ -1116,3 +1116,5 @@ CONFIG_CRYPTO_TEST=m<br>
#<br>
CONFIG_LIBCRC32C=m<br>
CONFIG_ZLIB_DEFLATE=m<br>
+<br>
+CONFIG_OVERLAY_FS=m<br>
diff --git a/ktypes/standard/standard.cfg b/ktypes/standard/standard.cfg<br>
index b3dbde5..3dabf49 100644<br>
--- a/ktypes/standard/standard.cfg<br>
+++ b/ktypes/standard/standard.cfg<br>
@@ -1108,3 +1108,5 @@ CONFIG_LIBCRC32C=m<br>
CONFIG_ZLIB_DEFLATE=m<br>
<br>
CONFIG_SHMEM=y<br>
+<br>
+CONFIG_OVERLAY_FS=m<span class=""><br>
<br></span></blockquote><div><br></div><div>Nope. See my follow up to the linux-yocto patch .. I was more detailed in my follow up<br></div><div>there.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2) let core-image-minimal-initramfs RDEPENEDS on the module.<br>
<br>
<br>
I'd still prefer that this be set in a distro or optional layer. Since why<br>
</blockquote>
<br></span>
The live/iso/hddimg is supported by oe-core, all of them are in oe-core layer,<br>
I'm afraid that we can't add it in an extra layer or bbappend.<span class=""><br><br></span></blockquote><div><br></div><div>Why not ? There are just as many image types that don't need this support. Why should<br></div><div>it be universally build and enabled for a feature that is only used by some boot types.<br></div><div><br></div><div>You are missing the point, and there's no justification to globally enable it.<br><br></div><div>What about flash boot, what about boot from specific MTD devices, etc, etc, should<br></div><div>they all be enabled by default in the base configs .. just in case someone boots that<br></div><div>way ? We'll end up with a giant kernel with everything enabled or as modules if we<br></div><div>cover all the cases. These need to be specifically requested and triggered.<br><br></div><div>Just because you are concerned with live iso boot, doesn't mean that others are,<br></div><div>and that we should have the overhead everywhere.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
should core image<br>
minimal be the target for this ? There are any number of targets that might be<br>
used for<br>
live boot.<br>
</blockquote>
<br></span>
All of them are in oe-core layer, <a href="http://core-image-minimal-initramfs.bb" rel="noreferrer" target="_blank">core-image-minimal-initramfs.bb</a> is the<br>
default live image in oe-core, I think that add kerne-module-overlay to<br>
its INSTALL is reasonable.<br></blockquote><div><br></div><div>But that shouldn't need overlayfs for all configs. I boot initramfs kernels all the time, I have no need<br></div><div>for overlay filesystems on those boards.<br><br></div><div>But yes, if you enable a module based overlayfs fragment, and then install the<br></div><div>module via an install, it should be ok, since it can be overridden.<br><br></div><div>I hope you are seeing the point of not enabling kernel options "just in case", and why<br></div><div>this sort of thing needs to be only built and installed when it is truly needed.<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>
If there are other layers which have their own live image, then they can add<br>
it to their INSTALL.<div class="HOEnZb"><div class="h5"><br>
<br>
// Robert<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Bruce<br>
<br>
// Robert<br>
<br>
<br>
Bruce<br>
<br>
<br>
// Robert<br>
<br>
On 04/04/2016 07:56 AM, Bruce Ashfield wrote:<br>
<br>
<br>
<br>
On Sun, Apr 3, 2016 at 5:46 PM, Richard Purdie<br>
<<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a><br>
<mailto:<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>><br>
<mailto:<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a><br>
<mailto:<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>>><br>
<mailto:<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a><br>
<mailto:<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>><br>
<mailto:<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a><br>
<mailto:<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>>>>><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>
><a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a><br>
<mailto:<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><br>
<mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a>>><br>
<mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a><br>
<mailto:<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><br>
<mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a>>>>><br>
<br>
wrote:<br>
> > So that iso can work well, otherwise the iso is<br>
readonly and there<br>
> > would<br>
> > be errors. The other way is aufs, but overlayfs is<br>
more pupolar and<br>
> > had<br>
> > been merged by kernel mainline, we need make iso work<br>
well by<br>
> > default.<br>
> Nope. As I mentioned before, this can't be a always on<br>
default. It<br>
> will conflict<br>
> with other unionFS use cases.<br>
><br>
> If you want overlayfs enabled, it needs to be triggered<br>
from a<br>
> specific image<br>
> or distro feature.<br>
<br>
We can't change the kernel config from an image so it<br>
would have to be<br>
a distro setting. Is there a problem with enabling both as<br>
modules btw?<br>
I assume they can coexist?<br>
<br>
<br>
I've always found it limiting that we can't trigger kernel<br>
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<br>
a layer<br>
that is<br>
added<br>
to the build, that has a bbappend with the appropriate<br>
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<br>
need a lot of<br>
streamlining),<br>
but building modules 'just in case' eventually leads to<br>
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<br>
await<br>
thee at its<br>
end"<br>
<br>
<br>
<br>
<br>
--<br>
"Thou shalt not follow the NULL pointer, for chaos and madness await<br>
thee at its<br>
end"<br>
<br>
<br>
<br>
<br>
--<br>
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its<br>
end"<br>
</blockquote>
</div></div></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>