Re: [PATCH 1/1] linux-yocto 4.4: enable overlayfs by default

[Robert Yang <liezhi.yang@windriver.com>]

On 04/05/2016 02:33 PM, Bruce Ashfield wrote:
>
>
> On Mon, Apr 4, 2016 at 10:48 PM, Robert Yang <liezhi.yang@windriver.com
> <mailto:liezhi.yang@windriver.com>> wrote:
>
>
>
>     On 04/05/2016 10:31 AM, Bruce Ashfield wrote:
>
>
>
>         On Mon, Apr 4, 2016 at 9:53 PM, Robert Yang <liezhi.yang@windriver.com
>         <mailto:liezhi.yang@windriver.com>
>         <mailto:liezhi.yang@windriver.com <mailto:liezhi.yang@windriver.com>>>
>         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.

How about this:

diff --git a/ktypes/preempt-rt/preempt-rt.cfg b/ktypes/preempt-rt/preempt-rt.cfg
index 4c62804..28ad8cf 100644
--- a/ktypes/preempt-rt/preempt-rt.cfg
+++ b/ktypes/preempt-rt/preempt-rt.cfg
@@ -1116,3 +1116,5 @@ CONFIG_CRYPTO_TEST=m
  #
  CONFIG_LIBCRC32C=m
  CONFIG_ZLIB_DEFLATE=m
+
+CONFIG_OVERLAY_FS=m
diff --git a/ktypes/standard/standard.cfg b/ktypes/standard/standard.cfg
index b3dbde5..3dabf49 100644
--- a/ktypes/standard/standard.cfg
+++ b/ktypes/standard/standard.cfg
@@ -1108,3 +1108,5 @@ CONFIG_LIBCRC32C=m
  CONFIG_ZLIB_DEFLATE=m

  CONFIG_SHMEM=y
+
+CONFIG_OVERLAY_FS=m


>
>     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

The live/iso/hddimg is supported by oe-core, all of them are in oe-core layer,
I'm afraid that we can't add it in an extra layer or bbappend.

> should core image
> minimal be the target for this ? There are any number of targets that might be
> used for
> live boot.

All of them are in oe-core layer, core-image-minimal-initramfs.bb is the
default live image in oe-core, I think that add kerne-module-overlay to
its INSTALL is reasonable.

If there are other layers which have their own live image, then they can add
it to their INSTALL.

// Robert

>
> 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
>                  <richard.purdie@linuxfoundation.org
>         <mailto:richard.purdie@linuxfoundation.org>
>                  <mailto:richard.purdie@linuxfoundation.org
>         <mailto:richard.purdie@linuxfoundation.org>>
>                  <mailto:richard.purdie@linuxfoundation.org
>         <mailto:richard.purdie@linuxfoundation.org>
>                  <mailto:richard.purdie@linuxfoundation.org
>         <mailto:richard.purdie@linuxfoundation.org>>>>
>                  wrote:
>
>                       On Sun, 2016-04-03 at 06:11 -0400, Bruce Ashfield wrote:
>                       >
>                       >
>                       > On Sun, Apr 3, 2016 at 5:58 AM, Robert Yang <
>                       >liezhi.yang@windriver.com
>         <mailto:liezhi.yang@windriver.com> <mailto:liezhi.yang@windriver.com
>         <mailto:liezhi.yang@windriver.com>>
>                  <mailto:liezhi.yang@windriver.com
>         <mailto:liezhi.yang@windriver.com> <mailto:liezhi.yang@windriver.com
>         <mailto:liezhi.yang@windriver.com>>>>
>
>                  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"