* [PATCH 0/1 V2] linux-yocto 4.4: enable overlayfs by default
@ 2016-04-03 9:58 Robert Yang
2016-04-03 9:58 ` [PATCH 1/1] " Robert Yang
2016-04-03 10:00 ` [PATCH 0/1 V2] " Robert Yang
0 siblings, 2 replies; 14+ messages in thread
From: Robert Yang @ 2016-04-03 9:58 UTC (permalink / raw)
To: openembedded-core
* 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(-)
--
2.8.0
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH 1/1] linux-yocto 4.4: enable overlayfs by default
2016-04-03 9:58 [PATCH 0/1 V2] linux-yocto 4.4: enable overlayfs by default Robert Yang
@ 2016-04-03 9:58 ` Robert Yang
2016-04-03 10:11 ` Bruce Ashfield
2016-04-03 10:00 ` [PATCH 0/1 V2] " Robert Yang
1 sibling, 1 reply; 14+ messages in thread
From: Robert Yang @ 2016-04-03 9:58 UTC (permalink / raw)
To: openembedded-core
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.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
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(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb b/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb
index 48025c4..4f3beb7 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb
@@ -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"
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.4.bb b/meta/recipes-kernel/linux/linux-yocto_4.4.bb
index 3d6991e..66bf956 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.4.bb
@@ -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"
--
2.8.0
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH 0/1 V2] linux-yocto 4.4: enable overlayfs by default
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:00 ` Robert Yang
1 sibling, 0 replies; 14+ messages in thread
From: Robert Yang @ 2016-04-03 10:00 UTC (permalink / raw)
To: Bruce Ashfield; +Cc: openembedded-core
Add Bruce in the loop.
// Robert
On 04/03/2016 05:58 PM, Robert Yang wrote:
> * 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(-)
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] linux-yocto 4.4: enable overlayfs by default
2016-04-03 9:58 ` [PATCH 1/1] " Robert Yang
@ 2016-04-03 10:11 ` Bruce Ashfield
2016-04-03 21:46 ` Richard Purdie
0 siblings, 1 reply; 14+ messages in thread
From: Bruce Ashfield @ 2016-04-03 10:11 UTC (permalink / raw)
To: Robert Yang; +Cc: Patches and discussions about the oe-core layer
[-- Attachment #1: Type: text/plain, Size: 2717 bytes --]
On Sun, Apr 3, 2016 at 5:58 AM, Robert Yang <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.
Bruce
>
> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
> ---
> 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(-)
>
> diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb
> b/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb
> index 48025c4..4f3beb7 100644
> --- a/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb
> @@ -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"
> diff --git a/meta/recipes-kernel/linux/linux-yocto_4.4.bb
> b/meta/recipes-kernel/linux/linux-yocto_4.4.bb
> index 3d6991e..66bf956 100644
> --- a/meta/recipes-kernel/linux/linux-yocto_4.4.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto_4.4.bb
> @@ -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"
> --
> 2.8.0
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
[-- Attachment #2: Type: text/html, Size: 4580 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] linux-yocto 4.4: enable overlayfs by default
2016-04-03 10:11 ` Bruce Ashfield
@ 2016-04-03 21:46 ` Richard Purdie
2016-04-03 23:56 ` Bruce Ashfield
0 siblings, 1 reply; 14+ messages in thread
From: Richard Purdie @ 2016-04-03 21:46 UTC (permalink / raw)
To: Bruce Ashfield, Robert Yang
Cc: Patches and discussions about the oe-core layer
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> 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?
Cheers,
Richard
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] linux-yocto 4.4: enable overlayfs by default
2016-04-03 21:46 ` Richard Purdie
@ 2016-04-03 23:56 ` Bruce Ashfield
2016-04-05 1:53 ` Robert Yang
0 siblings, 1 reply; 14+ messages in thread
From: Bruce Ashfield @ 2016-04-03 23:56 UTC (permalink / raw)
To: Richard Purdie; +Cc: Patches and discussions about the oe-core layer
[-- Attachment #1: Type: text/plain, Size: 1711 bytes --]
On Sun, Apr 3, 2016 at 5:46 PM, Richard Purdie <
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> 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"
[-- Attachment #2: Type: text/html, Size: 2614 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] linux-yocto 4.4: enable overlayfs by default
2016-04-03 23:56 ` Bruce Ashfield
@ 2016-04-05 1:53 ` Robert Yang
2016-04-05 2:31 ` Bruce Ashfield
0 siblings, 1 reply; 14+ messages in thread
From: Robert Yang @ 2016-04-05 1:53 UTC (permalink / raw)
To: Bruce Ashfield; +Cc: Patches and discussions about the oe-core layer
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
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>>
> 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>> 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"
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] linux-yocto 4.4: enable overlayfs by default
2016-04-05 1:53 ` Robert Yang
@ 2016-04-05 2:31 ` Bruce Ashfield
2016-04-05 2:48 ` Robert Yang
0 siblings, 1 reply; 14+ messages in thread
From: Bruce Ashfield @ 2016-04-05 2:31 UTC (permalink / raw)
To: Robert Yang; +Cc: Patches and discussions about the oe-core layer
[-- Attachment #1: Type: text/plain, Size: 3145 bytes --]
On Mon, Apr 4, 2016 at 9:53 PM, Robert Yang <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.
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>>
>> 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>> 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"
[-- Attachment #2: Type: text/html, Size: 4528 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] linux-yocto 4.4: enable overlayfs by default
2016-04-05 2:31 ` Bruce Ashfield
@ 2016-04-05 2:48 ` Robert Yang
2016-04-05 6:33 ` Bruce Ashfield
0 siblings, 1 reply; 14+ messages in thread
From: Robert Yang @ 2016-04-05 2:48 UTC (permalink / raw)
To: Bruce Ashfield; +Cc: Patches and discussions about the oe-core layer
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"
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] linux-yocto 4.4: enable overlayfs by default
2016-04-05 2:48 ` Robert Yang
@ 2016-04-05 6:33 ` Bruce Ashfield
2016-04-05 6:42 ` Robert Yang
0 siblings, 1 reply; 14+ messages in thread
From: Bruce Ashfield @ 2016-04-05 6:33 UTC (permalink / raw)
To: Robert Yang; +Cc: Patches and discussions about the oe-core layer
[-- Attachment #1: Type: text/plain, Size: 4782 bytes --]
On Mon, Apr 4, 2016 at 10:48 PM, Robert Yang <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>> 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.
> 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
> // 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"
>>
>
--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
[-- Attachment #2: Type: text/html, Size: 7132 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] linux-yocto 4.4: enable overlayfs by default
2016-04-05 6:33 ` Bruce Ashfield
@ 2016-04-05 6:42 ` Robert Yang
2016-04-05 8:33 ` Bruce Ashfield
0 siblings, 1 reply; 14+ messages in thread
From: Robert Yang @ 2016-04-05 6:42 UTC (permalink / raw)
To: Bruce Ashfield; +Cc: Patches and discussions about the oe-core layer
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"
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] linux-yocto 4.4: enable overlayfs by default
2016-04-05 6:42 ` Robert Yang
@ 2016-04-05 8:33 ` Bruce Ashfield
2016-04-05 9:06 ` Robert Yang
0 siblings, 1 reply; 14+ messages in thread
From: Bruce Ashfield @ 2016-04-05 8:33 UTC (permalink / raw)
To: Robert Yang; +Cc: Patches and discussions about the oe-core layer
[-- Attachment #1: Type: text/plain, Size: 9050 bytes --]
On Tue, Apr 5, 2016 at 2:42 AM, Robert Yang <liezhi.yang@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@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
>
>
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@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"
>>
>
--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
[-- Attachment #2: Type: text/html, Size: 13642 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] linux-yocto 4.4: enable overlayfs by default
2016-04-05 8:33 ` Bruce Ashfield
@ 2016-04-05 9:06 ` Robert Yang
2016-04-05 14:59 ` Bruce Ashfield
0 siblings, 1 reply; 14+ messages in thread
From: Robert Yang @ 2016-04-05 9:06 UTC (permalink / raw)
To: Bruce Ashfield; +Cc: Patches and discussions about the oe-core layer
On 04/05/2016 04:33 PM, Bruce Ashfield wrote:
>
>
> On Tue, Apr 5, 2016 at 2:42 AM, Robert Yang <liezhi.yang@windriver.com
> <mailto:liezhi.yang@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@windriver.com
> <mailto:liezhi.yang@windriver.com>
> <mailto: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>>
> <mailto: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
>
>
> Nope. 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 ?
>
>
>
> 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.
>
>
> 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 ?
>
> 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
>
> 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@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>>>
> <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
> <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>>>
> <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
> <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"
>
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its
> end"
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/1] linux-yocto 4.4: enable overlayfs by default
2016-04-05 9:06 ` Robert Yang
@ 2016-04-05 14:59 ` Bruce Ashfield
0 siblings, 0 replies; 14+ messages in thread
From: Bruce Ashfield @ 2016-04-05 14:59 UTC (permalink / raw)
To: Robert Yang; +Cc: Patches and discussions about the oe-core layer
[-- Attachment #1: Type: text/plain, Size: 17570 bytes --]
On Tue, Apr 5, 2016 at 5:06 AM, Robert Yang <liezhi.yang@windriver.com>
wrote:
>
>
> On 04/05/2016 04:33 PM, Bruce Ashfield wrote:
>
>>
>>
>> On Tue, Apr 5, 2016 at 2:42 AM, Robert Yang <liezhi.yang@windriver.com
>> <mailto:liezhi.yang@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@windriver.com
>> <mailto:liezhi.yang@windriver.com>
>> <mailto: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>>
>> <mailto: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
>>
>>
>> Nope. 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 ?
>
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 a
KERNEL_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!
>
>
>>
>>
>> 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.
>>
>>
>> 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 ?
>
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 ?
>
>
>> 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:
>
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.
>
> 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.
>
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
>
> // Robert
>
>
>
>> 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@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>>>
>> <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
>> <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>>>
>> <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
>> <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"
>>
>>
>>
>>
>> --
>> "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"
[-- Attachment #2: Type: text/html, Size: 25239 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2016-04-05 14:59 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox