linux-yocto 4.4: enable overlayfs by default
v2 cover linux-yocto 4.4: enable overlayfs by default
* V2
Rebase the patch based on Bruce's recent changes on kernel.
* V1
Initial version.
// Robert
The following changes since commit 322904f62f11e794543362f04212242567c556a0:
selftest/signing: Use packagedata to obtain PR value for signing test (2016-03-31 23:55:13 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib 637f6783157bb0e9449d153133485401bcf2dbb1
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=637f6783157bb0e9449d153133485401bcf2dbb1
Robert Yang (1):
linux-yocto 4.4: enable overlayfs by default
meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb | 2 +- meta/recipes-kernel/linux/linux-yocto_4.4.bb | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
Signature · 1 line
2.8.0
PATCH v2 1/1 linux-yocto 4.4: enable overlayfs by default
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.
--- meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb | 2 +- meta/recipes-kernel/linux/linux-yocto_4.4.bb | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb +1 -1
@@ -20,7 +20,7 @@ LINUX_KERNEL_TYPE = "preempt-rt" COMPATIBLE_MACHINE = "(qemux86|qemux86-64|qemuarm|qemuppc|qemumips)" # Functionality flags -KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc features/taskstats/taskstats.scc" +KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc features/taskstats/taskstats.scc features/overlayfs/overlayfs.scc" KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}" KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc" KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
meta/recipes-kernel/linux/linux-yocto_4.4.bb +1 -1
@@ -34,7 +34,7 @@ KCONF_BSP_AUDIT_LEVEL = "2" COMPATIBLE_MACHINE = "qemuarm|qemuarm64|qemux86|qemuppc|qemumips|qemumips64|qemux86-64" # Functionality flags -KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc" +KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc features/overlayfs/overlayfs.scc" KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}" KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc" KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
Signature · 1 line
2.8.0
Quoted 4 lines · Robert Yang
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.
Bruce
Quoted 48 lines
Signed-off-by Robert Yang <[email protected]>--- meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb | 2 +- meta/recipes-kernel/linux/linux-yocto_4.4.bb | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb +0
-1@@ -20,7 +20,7 @@ LINUX_KERNEL_TYPE = "preempt-rt" COMPATIBLE_MACHINE = "(qemux86|qemux86-64|qemuarm|qemuppc|qemumips)" # Functionality flags -KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.sccfeatures/taskstats/taskstats.scc"
+KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc features/taskstats/taskstats.scc features/overlayfs/overlayfs.scc"
KERNEL_FEATURES_append= " ${KERNEL_EXTRA_FEATURES}" KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc" KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"meta/recipes-kernel/linux/linux-yocto_4.4.bb +0
-0@@ -34,7 +34,7 @@ KCONF_BSP_AUDIT_LEVEL = "2" COMPATIBLE_MACHINE ="qemuarm|qemuarm64|qemux86|qemuppc|qemumips|qemumips64|qemux86-64"
# Functionality flags
meta/recipes-kernel/linux/linux-yocto_4.4.bb +1
-1-KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc" +KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.sccfeatures/overlayfs/overlayfs.scc"
KERNEL_FEATURES_append= " ${KERNEL_EXTRA_FEATURES}" KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc" KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
--
2.8.0--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
Quoted 10 lines · Bruce Ashfield
Quoted 6 lines · Robert Yang
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.
Quoted 7 lines
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?
Cheers,
Richard
Quoted 15 lines · Richard Purdie
Quoted 14 lines · Bruce Ashfield
Quoted 6 lines · Robert Yang
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.
Quoted 8 lines
Quoted 3 lines
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
Quoted 5 lines
Cheers,
Richard
Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
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.
// Robert
Quoted 58 lines · Bruce Ashfield
On Sun, Apr 3, 2016 at 5:46 PM, Richard Purdie <[email protected] <mailto:[email protected]>> wrote:
On Sun, 2016-04-03 at 06:11 -0400, Bruce Ashfield wrote:
>
>
> On Sun, Apr 3, 2016 at 5:58 AM, Robert Yang < >[email protected] <mailto:[email protected]>> 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 appropriateKERNEL_FEATURESwould 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"
Quoted 8 lines · Robert Yang
Hi Bruce,
How many union fs on Linux, please? AFAIK:
* unionfs: not supported by kernel any more.
* aufs
* overlayfs
Quoted 9 lines
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.
Bruce
Quoted 73 lines
// Robert
Quoted 67 lines · Bruce Ashfield
On Sun, Apr 3, 2016 at 5:46 PM, Richard Purdie
<[email protected] <mailto:
[email protected]>>
wrote:On Sun, 2016-04-03 at 06:11 -0400, Bruce Ashfield wrote:
>
>
> On Sun, Apr 3, 2016 at 5:58 AM, Robert Yang < >[email protected] <mailto:[email protected]>> 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
andQuoted 10 lines
Quoted 3 lines
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 appropriateKERNEL_FEATURESwould
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"
Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
Quoted 29 lines · Bruce Ashfield
On Mon, Apr 4, 2016 at 9:53 PM, Robert Yang <[email protected] <mailto:[email protected]>> wrote:
Hi Bruce,
How many union fs on Linux, please? AFAIK:
* unionfs: not supported by kernel any more.
* aufs
* overlayfsIf 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.
Quoted 5 lines
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
Quoted 80 lines
Bruce
// Robert
On 04/04/2016 07:56 AM, Bruce Ashfield wrote:
On Sun, Apr 3, 2016 at 5:46 PM, Richard Purdie <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> wrote:
On Sun, 2016-04-03 at 06:11 -0400, Bruce Ashfield wrote:
>
>
> On Sun, Apr 3, 2016 at 5:58 AM, Robert Yang < >[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> 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 appropriateKERNEL_FEATURESwould 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"
Quoted 44 lines · Robert Yang
Quoted 31 lines · Bruce Ashfield
On Mon, Apr 4, 2016 at 9:53 PM, Robert Yang <[email protected] <mailto:[email protected]>> wrote:
Hi Bruce,
How many union fs on Linux, please? AFAIK:
* unionfs: not supported by kernel any more.
* aufs
* overlayfsIf 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.Quoted 8 lines
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.
Quoted 4 lines
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.
Quoted 3 lines
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 should core image
minimal be the target for this ? There are any number of targets that might be used for
live boot.
Bruce
Quoted 102 lines
// Robert
Quoted 98 lines
Bruce
// Robert On 04/04/2016 07:56 AM, Bruce Ashfield wrote: On Sun, Apr 3, 2016 at 5:46 PM, Richard Purdie <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> wrote: On Sun, 2016-04-03 at 06:11 -0400, Bruce Ashfield wrote: > > > On Sun, Apr 3, 2016 at 5:58 AM, Robert Yang < >[email protected] <mailto:[email protected]Quoted 1 line
<mailto:[email protected] <mailto:
[email protected]>>>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 appropriateKERNEL_FEATURESwould
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"
Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
Quoted 50 lines · Bruce Ashfield
On Mon, Apr 4, 2016 at 10:48 PM, Robert Yang <[email protected] <mailto:[email protected]>> wrote:
On 04/05/2016 10:31 AM, Bruce Ashfield wrote:
On Mon, Apr 4, 2016 at 9:53 PM, Robert Yang <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> wrote:
Hi Bruce,
How many union fs on Linux, please? AFAIK:
* unionfs: not supported by kernel any more.
* aufs
* overlayfsIf 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.
Quoted 8 lines
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:
ktypes/preempt-rt/preempt-rt.cfg +2 -0
@@ -1116,3 +1116,5 @@ CONFIG_CRYPTO_TEST=m # CONFIG_LIBCRC32C=m CONFIG_ZLIB_DEFLATE=m + +CONFIG_OVERLAY_FS=m
ktypes/standard/standard.cfg +2 -0
@@ -1108,3 +1108,5 @@ CONFIG_LIBCRC32C=m CONFIG_ZLIB_DEFLATE=m CONFIG_SHMEM=y + +CONFIG_OVERLAY_FS=m
Quoted 5 lines
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.
Quoted 4 lines
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
Quoted 115 lines
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 <[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>
<mailto:[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>>
wrote:On Sun, 2016-04-03 at 06:11 -0400, Bruce Ashfield wrote:
>
>
> On Sun, Apr 3, 2016 at 5:58 AM, Robert Yang < >[email protected]
<mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>
<mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>>>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_FEATURESwould
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"
Quoted 92 lines · Robert Yang
Quoted 59 lines · Bruce Ashfield
On Mon, Apr 4, 2016 at 10:48 PM, Robert Yang <[email protected] <mailto:[email protected]>> wrote:
On 04/05/2016 10:31 AM, Bruce Ashfield wrote: On Mon, Apr 4, 2016 at 9:53 PM, Robert Yang <[email protected]
<mailto:[email protected]> <mailto:[email protected] <mailto:
[email protected]>>>
wrote:Hi Bruce,
How many union fs on Linux, please? AFAIK:
* unionfs: not supported by kernel any more.
* aufs
* overlayfsIf 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:
Quoted 8 lines
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:
ktypes/preempt-rt/preempt-rt.cfg +2
-0@@ -1116,3 +1116,5 @@ CONFIG_CRYPTO_TEST=m # CONFIG_LIBCRC32C=m CONFIG_ZLIB_DEFLATE=m + +CONFIG_OVERLAY_FS=mktypes/standard/standard.cfg +0
-0
ktypes/standard/standard.cfg CONFIG_LIBCRC32C=m · line 1112
Quoted 5 lines
ktypes/standard/standard.cfg +2
-0@@ -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.
Quoted 5 lines
Quoted 5 lines
2) let core-image-minimal-initramfs RDEPENEDS on the module.
Quoted 8 lines
Quoted 2 lines
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.
Quoted 8 lines
should core image
Quoted 5 lines
minimal be the target for this ? There are any number of targets that might be
used for
live boot.
Quoted 4 lines
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
Quoted 142 lines
If there are other layers which have their own live image, then they can add
it to their INSTALL.// Robert
Quoted 132 lines
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 <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>>> wrote: On Sun, 2016-04-03 at 06:11 -0400, Bruce Ashfield wrote: > > > On Sun, Apr 3, 2016 at 5:58 AM, Robert Yang < >[email protected] <mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
<mailto:[email protected]
<mailto:[email protected]> <mailto:
[email protected]
<mailto:[email protected]>>>>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_FEATURESwould
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"
Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
Quoted 99 lines · Bruce Ashfield
On Tue, Apr 5, 2016 at 2:42 AM, Robert Yang <[email protected] <mailto:[email protected]>> wrote:
On 04/05/2016 02:33 PM, Bruce Ashfield wrote:
On Mon, Apr 4, 2016 at 10:48 PM, Robert Yang <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> wrote:
On 04/05/2016 10:31 AM, Bruce Ashfield wrote:
On Mon, Apr 4, 2016 at 9:53 PM, Robert Yang
<[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>
<mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>>>
wrote:Hi Bruce,
How many union fs on Linux, please? AFAIK:
* unionfs: not supported by kernel any more.
* aufs
* overlayfsIf 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
Quoted 8 lines
CONFIG_SHMEM=y
+
+CONFIG_OVERLAY_FS=mNope. See my follow up to the linux-yocto patch .. I was more detailed in my follow up
there.
I read that just now, if we don't enable the module in oe-core layer or builtin it, I'm fine to leave the live image (iso, hddimg) broken by default and document that if you need a read write live image and fix the errors, you can enable it from KERNEL_FEATURES ?
Quoted 43 lines
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
<http://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.
Quoted 6 lines
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.
Did you mean it in oe-core or out of oe-core such as an external layer or bbappend, please ?
Quoted 4 lines
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.
I'm sorry, but I don't think that this is a "just in case" issue, live image is officially supported by oe-core, I think that we should release a workable image to the user rather than a half-finished one, currently, for example, the obvious errors when boot:
Populating dev cache/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create /etc/volatile.cache.build: Read-only file system /etc/rcS.d/S36udev-cache: line 73: can't create /etc/udev-cache.tar.gz: Read-only file system
udev-cache: update failed!/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create /etc/volatile.cache.build: Read-only file system
rm: can't remove '/etc/udev/cache.data': Read-only file system/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create /etc/volatile.cache.build: Read-only file system /etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create /etc/volatile.cache.build: Read-only file system /etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create /etc/volatile.cache.build: Read-only file system /etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create /etc/volatile.cache.build: Read-only file system /etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create /etc/volatile.cache.build: Read-only file system /etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create /etc/volatile.cache.build: Read-only file system /etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create /etc/volatile.cache.build: Read-only file system
rm: can't remove '/tmp': Read-only file system
ln: /tmp/tmp: Read-only file system/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create /etc/volatile.cache.build: Read-only file system /etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create /etc/volatile.cache.build: Read-only file system /etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create /etc/volatile.cache.build: Read-only file system
ln: /etc/resolv.conf: Read-only file system/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create /etc/volatile.cache.build: Read-only file system /etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create /etc/volatile.cache.build: Read-only file system
And it's readonly, the user can change nothing on the system when debug.
// Robert
Quoted 161 lines
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 <[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>
<mailto:[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>
<mailto:[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>
<mailto:[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>>>
wrote:On Sun, 2016-04-03 at 06:11 -0400, Bruce Ashfield
wrote:
>
>
> On Sun, Apr 3, 2016 at 5:58 AM, Robert Yang < >[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>
<mailto:[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>>>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_FEATURESwould
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"
Quoted 127 lines · Robert Yang
Quoted 117 lines · Bruce Ashfield
On Tue, Apr 5, 2016 at 2:42 AM, Robert Yang <[email protected] <mailto:[email protected]>> wrote:
On 04/05/2016 02:33 PM, Bruce Ashfield wrote: On Mon, Apr 4, 2016 at 10:48 PM, Robert Yang <[email protected]
<mailto:[email protected]> <mailto:[email protected] <mailto:
[email protected]>>>wrote: On 04/05/2016 10:31 AM, Bruce Ashfield wrote: On Mon, Apr 4, 2016 at 9:53 PM, Robert Yang <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>>
wrote:Hi Bruce,
How many union fs on Linux, please? AFAIK:
* unionfs: not supported by kernel any more.
* aufs
* overlayfsIf 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
builtinHaving 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.cfgindex 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=mQuoted 5 lines
Nope. See my follow up to the linux-yocto patch .. I was more detailed in my
follow up
there.
Quoted 5 lines
I read that just now, if we don't enable the module in oe-core layer or builtin it, I'm fine to leave the live image (iso, hddimg) broken by default and document that if you need a read write live image and fix the errors, you can enable it from
KERNEL_FEATURES?
It would still be nice to do that enablement without needing to rebuild the kernel completely.
Which is what we'll have if we only have a built-in fragment for overlayfs.
I was saying in my reviews, that having a module config fragment, and enabling it via aKERNEL_FEATURES in the main recipes would be ok, as long as that kernel feature
variable is easy to override and disable it. That gets them built, and available as packages
for image that want them.
I probably wasn't clear enough on that front, sorry about that!
Quoted 61 lines
Quoted 61 lines
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 whyThe 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
<http://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.
Quoted 8 lines
Quoted 4 lines
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.Did you mean it in oe-core or out of oe-core such as an external layer or bbappend, please ?
In a perfect world .. an external layer would be ideal, but we don't have great
selection of standard options for that (to use as a reference for the core image
type(s)). The yocto-bsps layer is one option .. but I don't think we want to
have this span multiple layers.
What I was saying above means that:
- you'd have a fragment that enabled the overlayfs modules
- you'd have then injected into the kernel config via a variable, that is then added to KERNEL_FEATURES.
That variable should be ?= so someone can override it if they see fit.
- your image types that need live boot, could generate the right RDEPENDS on the kernel package. That
could be in their image package lists, via a bbclass that generates the
dependency when included, or
something else that I'm not thinking about.
Am I missing something, or are you not using image-live.bbclass for this ? or is there some other
way that this is being enabled .. and that I'm missing ?
Quoted 9 lines
Quoted 8 lines
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.
Quoted 7 lines
I'm sorry, but I don't think that this is a "just in case" issue, live image
is officially supported by oe-core, I think that we should release a workable
image to the user rather than a half-finished one, currently, for example, the obvious errors when boot:
There are plenty of boot methods that are supported by the core layers, different
bootloaders, different devices, different fileystems (think btrfs, LVM, etc, etc). While
a simpler variant, this is in the same theme.
Quoted 38 lines
Populating dev cache
/etc/init.d/rc:/etc/rcS.d/S37populate-volatile.sh: line 1: can't create/etc/volatile.cache.build: Read-only file system/etc/rcS.d/S36udev-cache: line 73: can't create/etc/udev-cache.tar.gz:
Read-only file system
udev-cache: update failed!/etc/init.d/rc:/etc/rcS.d/S37populate-volatile.sh: line 1: can't create/etc/volatile.cache.build: Read-only file system
rm: can't remove '/etc/udev/cache.data': Read-only file system/etc/init.d/rc:/etc/rcS.d/S37populate-volatile.sh: line 1: can't create/etc/volatile.cache.build: Read-only file system/etc/init.d/rc:/etc/rcS.d/S37populate-volatile.sh: line 1: can't create/etc/volatile.cache.build: Read-only file system/etc/init.d/rc:/etc/rcS.d/S37populate-volatile.sh: line 1: can't create/etc/volatile.cache.build: Read-only file system/etc/init.d/rc:/etc/rcS.d/S37populate-volatile.sh: line 1: can't create/etc/volatile.cache.build: Read-only file system/etc/init.d/rc:/etc/rcS.d/S37populate-volatile.sh: line 1: can't create/etc/volatile.cache.build: Read-only file system/etc/init.d/rc:/etc/rcS.d/S37populate-volatile.sh: line 1: can't create/etc/volatile.cache.build: Read-only file system/etc/init.d/rc:/etc/rcS.d/S37populate-volatile.sh: line 1: can't create/etc/volatile.cache.build: Read-only file system
rm: can't remove '/tmp': Read-only file system
ln:/tmp/tmp: Read-only file system/etc/init.d/rc:/etc/rcS.d/S37populate-volatile.sh: line 1: can't create/etc/volatile.cache.build: Read-only file system/etc/init.d/rc:/etc/rcS.d/S37populate-volatile.sh: line 1: can't create/etc/volatile.cache.build: Read-only file system/etc/init.d/rc:/etc/rcS.d/S37populate-volatile.sh: line 1: can't create/etc/volatile.cache.build: Read-only file system
ln:/etc/resolv.conf: Read-only file system/etc/init.d/rc:/etc/rcS.d/S37populate-volatile.sh: line 1: can't create/etc/volatile.cache.build: Read-only file system/etc/init.d/rc:/etc/rcS.d/S37populate-volatile.sh: line 1: can't create/etc/volatile.cache.build: Read-only file system
Quoted 2 lines
And it's readonly, the user can change nothing on the system when debug.
Yes, we use union filesystems to do read-only boots, but there other ways to do it (and we have
in the past supported live, read only boots .. without a unionfs at all).
Through this whole exercise, I'm just trying to prevent focus on a single, current, solution and make
sure that it is flexible for when it inevitably changes in the future, and to not have a trend of needing
to build in configs like this to support a set of different boot methods. Since we can no more control
those methods, than we can control the use of a specific kernel, or kernel config.
If you want, we can work this out via some IRC discussions, etc, to save everyone getting spammed :)
Cheers,
Bruce
Quoted 187 lines
// Robert
Quoted 181 lines
Bruce
If there are other layers which have their own live image, then they
can addit 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 <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>>>> wrote: On Sun, 2016-04-03 at 06:11 -0400, Bruce Ashfield wrote: > > > On Sun, Apr 3, 2016 at 5:58 AM, RobertYang <
>[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>> <mailto:
[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>
<mailto:[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>> <mailto:
[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>>>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_FEATURESwould
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"
Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
Add Bruce in the loop.
// Robert
Quoted 24 lines · Robert Yang
* V2
Rebase the patch based on Bruce's recent changes on kernel.* V1
Initial version.// Robert
The following changes since commit
322904f62f11e794543362f04212242567c556a0:selftest/signing: Use packagedata to obtain PR value for signing test (2016-03-31 23:55:13 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib 637f6783157bb0e9449d153133485401bcf2dbb1 http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=637f6783157bb0e9449d153133485401bcf2dbb1Robert Yang (1):
linux-yocto 4.4: enable overlayfs by defaultmeta/recipes-kernel/linux/linux-yocto-rt_4.4.bb | 2 +- meta/recipes-kernel/linux/linux-yocto_4.4.bb | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)