[OE-core] [PATCH 1/1] linux-yocto 4.4: enable overlayfs by default
Bruce Ashfield
bruce.ashfield at gmail.com
Tue Apr 5 08:33:37 UTC 2016
On Tue, Apr 5, 2016 at 2:42 AM, Robert Yang <liezhi.yang at windriver.com>
wrote:
>
>
> On 04/05/2016 02:33 PM, Bruce Ashfield wrote:
>
>>
>>
>> On Mon, Apr 4, 2016 at 10:48 PM, Robert Yang <liezhi.yang at windriver.com
>> <mailto:liezhi.yang at 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 at windriver.com
>> <mailto:liezhi.yang at windriver.com>
>> <mailto:liezhi.yang at windriver.com <mailto:
>> liezhi.yang at 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
>
>
Nope. See my follow up to the linux-yocto patch .. I was more detailed in
my follow up
there.
>
>
>> 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.
>
>
Why not ? There are just as many image types that don't need this support.
Why should
it be universally build and enabled for a feature that is only used by some
boot types.
You are missing the point, and there's no justification to globally enable
it.
What about flash boot, what about boot from specific MTD devices, etc, etc,
should
they all be enabled by default in the base configs .. just in case someone
boots that
way ? We'll end up with a giant kernel with everything enabled or as
modules if we
cover all the cases. These need to be specifically requested and triggered.
Just because you are concerned with live iso boot, doesn't mean that others
are,
and that we should have the overhead everywhere.
>
> 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.
>
But that shouldn't need overlayfs for all configs. I boot initramfs kernels
all the time, I have no need
for overlay filesystems on those boards.
But yes, if you enable a module based overlayfs fragment, and then install
the
module via an install, it should be ok, since it can be overridden.
I hope you are seeing the point of not enabling kernel options "just in
case", and why
this sort of thing needs to be only built and installed when it is truly
needed.
Bruce
>
> 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 at linuxfoundation.org
>> <mailto:richard.purdie at linuxfoundation.org>
>> <mailto:richard.purdie at linuxfoundation.org
>> <mailto:richard.purdie at linuxfoundation.org>>
>> <mailto:richard.purdie at linuxfoundation.org
>> <mailto:richard.purdie at linuxfoundation.org>
>> <mailto:richard.purdie at linuxfoundation.org
>> <mailto:richard.purdie at 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 at windriver.com
>> <mailto:liezhi.yang at windriver.com> <mailto:
>> liezhi.yang at windriver.com
>> <mailto:liezhi.yang at windriver.com>>
>> <mailto:liezhi.yang at windriver.com
>> <mailto:liezhi.yang at windriver.com> <mailto:
>> liezhi.yang at windriver.com
>> <mailto:liezhi.yang at 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"
>>
>
--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160405/3f2a8187/attachment-0002.html>
More information about the Openembedded-core
mailing list