Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Robert Yang <liezhi.yang@windriver.com>
To: Bruce Ashfield <bruce.ashfield@gmail.com>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 1/1] linux-yocto 4.4: enable overlayfs by default
Date: Tue, 5 Apr 2016 10:48:54 +0800	[thread overview]
Message-ID: <57032796.3020302@windriver.com> (raw)
In-Reply-To: <CADkTA4M=kwVZnHi-3EfdjkhV4rA6Ep+hWw3EpZrcfu3Q7pz85A@mail.gmail.com>



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


  reply	other threads:[~2016-04-05  2:48 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-03  9:58 [PATCH 0/1 V2] linux-yocto 4.4: enable overlayfs by default Robert Yang
2016-04-03  9:58 ` [PATCH 1/1] " Robert Yang
2016-04-03 10:11   ` Bruce Ashfield
2016-04-03 21:46     ` Richard Purdie
2016-04-03 23:56       ` Bruce Ashfield
2016-04-05  1:53         ` Robert Yang
2016-04-05  2:31           ` Bruce Ashfield
2016-04-05  2:48             ` Robert Yang [this message]
2016-04-05  6:33               ` Bruce Ashfield
2016-04-05  6:42                 ` Robert Yang
2016-04-05  8:33                   ` Bruce Ashfield
2016-04-05  9:06                     ` Robert Yang
2016-04-05 14:59                       ` Bruce Ashfield
2016-04-03 10:00 ` [PATCH 0/1 V2] " Robert Yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57032796.3020302@windriver.com \
    --to=liezhi.yang@windriver.com \
    --cc=bruce.ashfield@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox