* [PATCH 1/3] kernel.bbclass: do not install initramfs bundled kernel image
2016-01-05 13:12 [PATCH 0/3] Introduces kernel-initramfs recipe to resolve a implicit dependency issue Ming Liu
@ 2016-01-05 13:12 ` Ming Liu
2016-01-19 19:39 ` Bruce Ashfield
2016-01-05 13:12 ` [PATCH 2/3] image.bbclass: removes bundle_initramfs related code Ming Liu
` (3 subsequent siblings)
4 siblings, 1 reply; 17+ messages in thread
From: Ming Liu @ 2016-01-05 13:12 UTC (permalink / raw)
To: openembedded-core; +Cc: bruce.ashfield, yue.tao, Ming Liu
From: Ming Liu <peter.x.liu@external.atlascopco.com>
It makes no sense to install a initramfs bundled kernel image since
do_package does not depend on do_bundle_initramfs at all, otherwise, it
leads to a implicit kernel-image package depending on do_package run before
or after do_bundle_initramfs.
Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com>
---
meta/classes/kernel.bbclass | 4 ----
1 file changed, 4 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 4ce1611..d1ca614 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -179,10 +179,6 @@ do_bundle_initramfs () {
kernel_do_compile
mv -f ${KERNEL_OUTPUT} ${KERNEL_OUTPUT}.initramfs
mv -f ${KERNEL_OUTPUT}.bak ${KERNEL_OUTPUT}
- # Update install area
- echo "There is kernel image bundled with initramfs: ${B}/${KERNEL_OUTPUT}.initramfs"
- install -m 0644 ${B}/${KERNEL_OUTPUT}.initramfs ${D}/boot/${KERNEL_IMAGETYPE}-initramfs-${MACHINE}.bin
- echo "${B}/${KERNEL_OUTPUT}.initramfs"
fi
}
--
1.9.1
^ permalink raw reply related [flat|nested] 17+ messages in thread* Re: [PATCH 1/3] kernel.bbclass: do not install initramfs bundled kernel image
2016-01-05 13:12 ` [PATCH 1/3] kernel.bbclass: do not install initramfs bundled kernel image Ming Liu
@ 2016-01-19 19:39 ` Bruce Ashfield
2016-01-19 21:57 ` Ming Liu
0 siblings, 1 reply; 17+ messages in thread
From: Bruce Ashfield @ 2016-01-19 19:39 UTC (permalink / raw)
To: Ming Liu, openembedded-core; +Cc: yue.tao, Ming Liu
On 16-01-05 08:12 AM, Ming Liu wrote:
> From: Ming Liu <peter.x.liu@external.atlascopco.com>
>
> It makes no sense to install a initramfs bundled kernel image since
> do_package does not depend on do_bundle_initramfs at all, otherwise, it
> leads to a implicit kernel-image package depending on do_package run before
> or after do_bundle_initramfs.
Again. So why not just add the ordering in the task dependencies ?
I'm probably missing something, which just means we need to tweak
the commit log a bit more.
The code you are removing is conditional, and is run after an
explicit kernel_do_compile is called, to rebuild the existing
kernel configuration with an embedded initramfs (via alternate initrd).
So outside of some ordering/parallel execution issues, I'm not seeing
it as broken.
Bruce
>
> Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com>
> ---
> meta/classes/kernel.bbclass | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index 4ce1611..d1ca614 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -179,10 +179,6 @@ do_bundle_initramfs () {
> kernel_do_compile
> mv -f ${KERNEL_OUTPUT} ${KERNEL_OUTPUT}.initramfs
> mv -f ${KERNEL_OUTPUT}.bak ${KERNEL_OUTPUT}
> - # Update install area
> - echo "There is kernel image bundled with initramfs: ${B}/${KERNEL_OUTPUT}.initramfs"
> - install -m 0644 ${B}/${KERNEL_OUTPUT}.initramfs ${D}/boot/${KERNEL_IMAGETYPE}-initramfs-${MACHINE}.bin
> - echo "${B}/${KERNEL_OUTPUT}.initramfs"
> fi
> }
>
>
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 1/3] kernel.bbclass: do not install initramfs bundled kernel image
2016-01-19 19:39 ` Bruce Ashfield
@ 2016-01-19 21:57 ` Ming Liu
2016-01-20 4:43 ` Bruce Ashfield
0 siblings, 1 reply; 17+ messages in thread
From: Ming Liu @ 2016-01-19 21:57 UTC (permalink / raw)
To: Bruce Ashfield, openembedded-core; +Cc: yue.tao, Ming Liu
On 01/19/2016 08:39 PM, Bruce Ashfield wrote:
> On 16-01-05 08:12 AM, Ming Liu wrote:
>> From: Ming Liu <peter.x.liu@external.atlascopco.com>
>>
>> It makes no sense to install a initramfs bundled kernel image since
>> do_package does not depend on do_bundle_initramfs at all, otherwise, it
>> leads to a implicit kernel-image package depending on do_package run
>> before
>> or after do_bundle_initramfs.
>
> Again. So why not just add the ordering in the task dependencies ?
If we add a intertask dependency like:
add bundle_initramfs before do_install after do_deploy do_package
Then it will somehow introduce a circular dependency as I described in
another mail.
>
> I'm probably missing something, which just means we need to tweak
> the commit log a bit more.
Maybe I should add some description in commit log about why I think we
could not introduce a intertask dependency as a fix.
>
> The code you are removing is conditional, and is run after an
> explicit kernel_do_compile is called, to rebuild the existing
> kernel configuration with an embedded initramfs (via alternate initrd).
> So outside of some ordering/parallel execution issues, I'm not seeing
> it as broken.
Yes, I agree, it will not break the kernel re-compiling, the problem I
want to fix here is just that it does not provide a certain way that we
could add initramfs bundled kernel image into a rootfs.
//Ming Liu
>
> Bruce
>
>>
>> Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com>
>> ---
>> meta/classes/kernel.bbclass | 4 ----
>> 1 file changed, 4 deletions(-)
>>
>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>> index 4ce1611..d1ca614 100644
>> --- a/meta/classes/kernel.bbclass
>> +++ b/meta/classes/kernel.bbclass
>> @@ -179,10 +179,6 @@ do_bundle_initramfs () {
>> kernel_do_compile
>> mv -f ${KERNEL_OUTPUT} ${KERNEL_OUTPUT}.initramfs
>> mv -f ${KERNEL_OUTPUT}.bak ${KERNEL_OUTPUT}
>> - # Update install area
>> - echo "There is kernel image bundled with initramfs:
>> ${B}/${KERNEL_OUTPUT}.initramfs"
>> - install -m 0644 ${B}/${KERNEL_OUTPUT}.initramfs
>> ${D}/boot/${KERNEL_IMAGETYPE}-initramfs-${MACHINE}.bin
>> - echo "${B}/${KERNEL_OUTPUT}.initramfs"
>> fi
>> }
>>
>>
>
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 1/3] kernel.bbclass: do not install initramfs bundled kernel image
2016-01-19 21:57 ` Ming Liu
@ 2016-01-20 4:43 ` Bruce Ashfield
2016-01-20 23:29 ` Ming Liu
0 siblings, 1 reply; 17+ messages in thread
From: Bruce Ashfield @ 2016-01-20 4:43 UTC (permalink / raw)
To: Ming Liu, openembedded-core; +Cc: yue.tao, Ming Liu
On 2016-01-19 4:57 PM, Ming Liu wrote:
>
>
> On 01/19/2016 08:39 PM, Bruce Ashfield wrote:
>> On 16-01-05 08:12 AM, Ming Liu wrote:
>>> From: Ming Liu <peter.x.liu@external.atlascopco.com>
>>>
>>> It makes no sense to install a initramfs bundled kernel image since
>>> do_package does not depend on do_bundle_initramfs at all, otherwise, it
>>> leads to a implicit kernel-image package depending on do_package run
>>> before
>>> or after do_bundle_initramfs.
>>
>> Again. So why not just add the ordering in the task dependencies ?
> If we add a intertask dependency like:
> add bundle_initramfs before do_install after do_deploy do_package
>
> Then it will somehow introduce a circular dependency as I described in
> another mail.
>>
>> I'm probably missing something, which just means we need to tweak
>> the commit log a bit more.
> Maybe I should add some description in commit log about why I think we
> could not introduce a intertask dependency as a fix.
>
That would be ideal, the more information the better.
>>
>> The code you are removing is conditional, and is run after an
>> explicit kernel_do_compile is called, to rebuild the existing
>> kernel configuration with an embedded initramfs (via alternate initrd).
>> So outside of some ordering/parallel execution issues, I'm not seeing
>> it as broken.
> Yes, I agree, it will not break the kernel re-compiling, the problem I
> want to fix here is just that it does not provide a certain way that we
> could add initramfs bundled kernel image into a rootfs.
>
Speaking of breaking. What happens to existing users of INITRAMFS_IMAGE?
Do their existing image types and bundling continue to work without
modification ?
Bruce
> //Ming Liu
>>
>> Bruce
>>
>>>
>>> Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com>
>>> ---
>>> meta/classes/kernel.bbclass | 4 ----
>>> 1 file changed, 4 deletions(-)
>>>
>>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>>> index 4ce1611..d1ca614 100644
>>> --- a/meta/classes/kernel.bbclass
>>> +++ b/meta/classes/kernel.bbclass
>>> @@ -179,10 +179,6 @@ do_bundle_initramfs () {
>>> kernel_do_compile
>>> mv -f ${KERNEL_OUTPUT} ${KERNEL_OUTPUT}.initramfs
>>> mv -f ${KERNEL_OUTPUT}.bak ${KERNEL_OUTPUT}
>>> - # Update install area
>>> - echo "There is kernel image bundled with initramfs:
>>> ${B}/${KERNEL_OUTPUT}.initramfs"
>>> - install -m 0644 ${B}/${KERNEL_OUTPUT}.initramfs
>>> ${D}/boot/${KERNEL_IMAGETYPE}-initramfs-${MACHINE}.bin
>>> - echo "${B}/${KERNEL_OUTPUT}.initramfs"
>>> fi
>>> }
>>>
>>>
>>
>
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 1/3] kernel.bbclass: do not install initramfs bundled kernel image
2016-01-20 4:43 ` Bruce Ashfield
@ 2016-01-20 23:29 ` Ming Liu
2016-01-22 20:39 ` Bruce Ashfield
0 siblings, 1 reply; 17+ messages in thread
From: Ming Liu @ 2016-01-20 23:29 UTC (permalink / raw)
To: Bruce Ashfield, openembedded-core; +Cc: yue.tao, Ming Liu
On 01/20/2016 05:43 AM, Bruce Ashfield wrote:
> On 2016-01-19 4:57 PM, Ming Liu wrote:
>>
>>
>> On 01/19/2016 08:39 PM, Bruce Ashfield wrote:
>>> On 16-01-05 08:12 AM, Ming Liu wrote:
>>>> From: Ming Liu <peter.x.liu@external.atlascopco.com>
>>>>
>>>> It makes no sense to install a initramfs bundled kernel image since
>>>> do_package does not depend on do_bundle_initramfs at all,
>>>> otherwise, it
>>>> leads to a implicit kernel-image package depending on do_package run
>>>> before
>>>> or after do_bundle_initramfs.
>>>
>>> Again. So why not just add the ordering in the task dependencies ?
>> If we add a intertask dependency like:
>> add bundle_initramfs before do_install after do_deploy do_package
>>
>> Then it will somehow introduce a circular dependency as I described in
>> another mail.
>>>
>>> I'm probably missing something, which just means we need to tweak
>>> the commit log a bit more.
>> Maybe I should add some description in commit log about why I think we
>> could not introduce a intertask dependency as a fix.
>>
>
> That would be ideal, the more information the better.
>
>>>
>>> The code you are removing is conditional, and is run after an
>>> explicit kernel_do_compile is called, to rebuild the existing
>>> kernel configuration with an embedded initramfs (via alternate initrd).
>>> So outside of some ordering/parallel execution issues, I'm not seeing
>>> it as broken.
>> Yes, I agree, it will not break the kernel re-compiling, the problem I
>> want to fix here is just that it does not provide a certain way that we
>> could add initramfs bundled kernel image into a rootfs.
>>
>
> Speaking of breaking. What happens to existing users of INITRAMFS_IMAGE?
> Do their existing image types and bundling continue to work without
> modification ?
That depends, the existing users always can find the INITRAMFS_IMAGE
bundled kernel in DEPLOY_DIR with or without my patches, it is not
broken. But if they want it installed in the rootfs, for some reasons,
they will have the problem, like in my company, we want to boot the
kernel from /boot/ on a USB disk, but it is not guaranteed we will get
the INITRAMFS_IMAGE bundled kernel there during the build.
//Ming Liu
>
> Bruce
>
>> //Ming Liu
>>>
>>> Bruce
>>>
>>>>
>>>> Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com>
>>>> ---
>>>> meta/classes/kernel.bbclass | 4 ----
>>>> 1 file changed, 4 deletions(-)
>>>>
>>>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>>>> index 4ce1611..d1ca614 100644
>>>> --- a/meta/classes/kernel.bbclass
>>>> +++ b/meta/classes/kernel.bbclass
>>>> @@ -179,10 +179,6 @@ do_bundle_initramfs () {
>>>> kernel_do_compile
>>>> mv -f ${KERNEL_OUTPUT} ${KERNEL_OUTPUT}.initramfs
>>>> mv -f ${KERNEL_OUTPUT}.bak ${KERNEL_OUTPUT}
>>>> - # Update install area
>>>> - echo "There is kernel image bundled with initramfs:
>>>> ${B}/${KERNEL_OUTPUT}.initramfs"
>>>> - install -m 0644 ${B}/${KERNEL_OUTPUT}.initramfs
>>>> ${D}/boot/${KERNEL_IMAGETYPE}-initramfs-${MACHINE}.bin
>>>> - echo "${B}/${KERNEL_OUTPUT}.initramfs"
>>>> fi
>>>> }
>>>>
>>>>
>>>
>>
>
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 1/3] kernel.bbclass: do not install initramfs bundled kernel image
2016-01-20 23:29 ` Ming Liu
@ 2016-01-22 20:39 ` Bruce Ashfield
2016-01-26 22:12 ` Ming Liu
0 siblings, 1 reply; 17+ messages in thread
From: Bruce Ashfield @ 2016-01-22 20:39 UTC (permalink / raw)
To: Ming Liu, openembedded-core; +Cc: Tao, Yue, Ming Liu
On 16-01-20 6:29 PM, Ming Liu wrote:
>
>
> On 01/20/2016 05:43 AM, Bruce Ashfield wrote:
>> On 2016-01-19 4:57 PM, Ming Liu wrote:
>>>
>>>
>>> On 01/19/2016 08:39 PM, Bruce Ashfield wrote:
>>>> On 16-01-05 08:12 AM, Ming Liu wrote:
>>>>> From: Ming Liu <peter.x.liu@external.atlascopco.com>
>>>>>
>>>>> It makes no sense to install a initramfs bundled kernel image since
>>>>> do_package does not depend on do_bundle_initramfs at all,
>>>>> otherwise, it
>>>>> leads to a implicit kernel-image package depending on do_package run
>>>>> before
>>>>> or after do_bundle_initramfs.
>>>>
>>>> Again. So why not just add the ordering in the task dependencies ?
>>> If we add a intertask dependency like:
>>> add bundle_initramfs before do_install after do_deploy do_package
>>>
>>> Then it will somehow introduce a circular dependency as I described in
>>> another mail.
>>>>
>>>> I'm probably missing something, which just means we need to tweak
>>>> the commit log a bit more.
>>> Maybe I should add some description in commit log about why I think we
>>> could not introduce a intertask dependency as a fix.
>>>
>>
>> That would be ideal, the more information the better.
>>
>>>>
>>>> The code you are removing is conditional, and is run after an
>>>> explicit kernel_do_compile is called, to rebuild the existing
>>>> kernel configuration with an embedded initramfs (via alternate initrd).
>>>> So outside of some ordering/parallel execution issues, I'm not seeing
>>>> it as broken.
>>> Yes, I agree, it will not break the kernel re-compiling, the problem I
>>> want to fix here is just that it does not provide a certain way that we
>>> could add initramfs bundled kernel image into a rootfs.
>>>
>>
>> Speaking of breaking. What happens to existing users of INITRAMFS_IMAGE?
>> Do their existing image types and bundling continue to work without
>> modification ?
> That depends, the existing users always can find the INITRAMFS_IMAGE
> bundled kernel in DEPLOY_DIR with or without my patches, it is not
> broken. But if they want it installed in the rootfs, for some reasons,
> they will have the problem, like in my company, we want to boot the
> kernel from /boot/ on a USB disk, but it is not guaranteed we will get
> the INITRAMFS_IMAGE bundled kernel there during the build.
Right. And if someone isn't doing any initramfs bundling, is there
any impact ? No variables to change, etc ?
I'd suggest double checking meta-initramfs:
http://layers.openembedded.org/layerindex/branch/master/layer/meta-initramfs/
And checking with Andrea to be sure that none of the existing use
cases are broken.
Bruce
>
> //Ming Liu
>>
>> Bruce
>>
>>> //Ming Liu
>>>>
>>>> Bruce
>>>>
>>>>>
>>>>> Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com>
>>>>> ---
>>>>> meta/classes/kernel.bbclass | 4 ----
>>>>> 1 file changed, 4 deletions(-)
>>>>>
>>>>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>>>>> index 4ce1611..d1ca614 100644
>>>>> --- a/meta/classes/kernel.bbclass
>>>>> +++ b/meta/classes/kernel.bbclass
>>>>> @@ -179,10 +179,6 @@ do_bundle_initramfs () {
>>>>> kernel_do_compile
>>>>> mv -f ${KERNEL_OUTPUT} ${KERNEL_OUTPUT}.initramfs
>>>>> mv -f ${KERNEL_OUTPUT}.bak ${KERNEL_OUTPUT}
>>>>> - # Update install area
>>>>> - echo "There is kernel image bundled with initramfs:
>>>>> ${B}/${KERNEL_OUTPUT}.initramfs"
>>>>> - install -m 0644 ${B}/${KERNEL_OUTPUT}.initramfs
>>>>> ${D}/boot/${KERNEL_IMAGETYPE}-initramfs-${MACHINE}.bin
>>>>> - echo "${B}/${KERNEL_OUTPUT}.initramfs"
>>>>> fi
>>>>> }
>>>>>
>>>>>
>>>>
>>>
>>
>
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 1/3] kernel.bbclass: do not install initramfs bundled kernel image
2016-01-22 20:39 ` Bruce Ashfield
@ 2016-01-26 22:12 ` Ming Liu
2016-01-26 23:22 ` Andrea Adami
0 siblings, 1 reply; 17+ messages in thread
From: Ming Liu @ 2016-01-26 22:12 UTC (permalink / raw)
To: Bruce Ashfield, openembedded-core; +Cc: Tao, Yue, Ming Liu
On 01/22/2016 09:39 PM, Bruce Ashfield wrote:
> On 16-01-20 6:29 PM, Ming Liu wrote:
>>
>>
>> On 01/20/2016 05:43 AM, Bruce Ashfield wrote:
>>> On 2016-01-19 4:57 PM, Ming Liu wrote:
>>>>
>>>>
>>>> On 01/19/2016 08:39 PM, Bruce Ashfield wrote:
>>>>> On 16-01-05 08:12 AM, Ming Liu wrote:
>>>>>> From: Ming Liu <peter.x.liu@external.atlascopco.com>
>>>>>>
>>>>>> It makes no sense to install a initramfs bundled kernel image since
>>>>>> do_package does not depend on do_bundle_initramfs at all,
>>>>>> otherwise, it
>>>>>> leads to a implicit kernel-image package depending on do_package run
>>>>>> before
>>>>>> or after do_bundle_initramfs.
>>>>>
>>>>> Again. So why not just add the ordering in the task dependencies ?
>>>> If we add a intertask dependency like:
>>>> add bundle_initramfs before do_install after do_deploy do_package
>>>>
>>>> Then it will somehow introduce a circular dependency as I described in
>>>> another mail.
>>>>>
>>>>> I'm probably missing something, which just means we need to tweak
>>>>> the commit log a bit more.
>>>> Maybe I should add some description in commit log about why I think we
>>>> could not introduce a intertask dependency as a fix.
>>>>
>>>
>>> That would be ideal, the more information the better.
>>>
>>>>>
>>>>> The code you are removing is conditional, and is run after an
>>>>> explicit kernel_do_compile is called, to rebuild the existing
>>>>> kernel configuration with an embedded initramfs (via alternate
>>>>> initrd).
>>>>> So outside of some ordering/parallel execution issues, I'm not seeing
>>>>> it as broken.
>>>> Yes, I agree, it will not break the kernel re-compiling, the problem I
>>>> want to fix here is just that it does not provide a certain way
>>>> that we
>>>> could add initramfs bundled kernel image into a rootfs.
>>>>
>>>
>>> Speaking of breaking. What happens to existing users of
>>> INITRAMFS_IMAGE?
>>> Do their existing image types and bundling continue to work without
>>> modification ?
>> That depends, the existing users always can find the INITRAMFS_IMAGE
>> bundled kernel in DEPLOY_DIR with or without my patches, it is not
>> broken. But if they want it installed in the rootfs, for some reasons,
>> they will have the problem, like in my company, we want to boot the
>> kernel from /boot/ on a USB disk, but it is not guaranteed we will get
>> the INITRAMFS_IMAGE bundled kernel there during the build.
>
> Right. And if someone isn't doing any initramfs bundling, is there
> any impact ? No variables to change, etc ?
Would not impact, no need to change any variables.
>
> I'd suggest double checking meta-initramfs:
>
> http://layers.openembedded.org/layerindex/branch/master/layer/meta-initramfs/
>
>
OK, I will do that and let you know the results.
> And checking with Andrea to be sure that none of the existing use
> cases are broken.
>
OK, I will check with Andrea after I finished the tests with
meta-initramfs layer.
//Ming Liu
> Bruce
>
>>
>> //Ming Liu
>>>
>>> Bruce
>>>
>>>> //Ming Liu
>>>>>
>>>>> Bruce
>>>>>
>>>>>>
>>>>>> Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com>
>>>>>> ---
>>>>>> meta/classes/kernel.bbclass | 4 ----
>>>>>> 1 file changed, 4 deletions(-)
>>>>>>
>>>>>> diff --git a/meta/classes/kernel.bbclass
>>>>>> b/meta/classes/kernel.bbclass
>>>>>> index 4ce1611..d1ca614 100644
>>>>>> --- a/meta/classes/kernel.bbclass
>>>>>> +++ b/meta/classes/kernel.bbclass
>>>>>> @@ -179,10 +179,6 @@ do_bundle_initramfs () {
>>>>>> kernel_do_compile
>>>>>> mv -f ${KERNEL_OUTPUT} ${KERNEL_OUTPUT}.initramfs
>>>>>> mv -f ${KERNEL_OUTPUT}.bak ${KERNEL_OUTPUT}
>>>>>> - # Update install area
>>>>>> - echo "There is kernel image bundled with initramfs:
>>>>>> ${B}/${KERNEL_OUTPUT}.initramfs"
>>>>>> - install -m 0644 ${B}/${KERNEL_OUTPUT}.initramfs
>>>>>> ${D}/boot/${KERNEL_IMAGETYPE}-initramfs-${MACHINE}.bin
>>>>>> - echo "${B}/${KERNEL_OUTPUT}.initramfs"
>>>>>> fi
>>>>>> }
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 1/3] kernel.bbclass: do not install initramfs bundled kernel image
2016-01-26 22:12 ` Ming Liu
@ 2016-01-26 23:22 ` Andrea Adami
0 siblings, 0 replies; 17+ messages in thread
From: Andrea Adami @ 2016-01-26 23:22 UTC (permalink / raw)
To: Ming Liu; +Cc: Bruce Ashfield, Tao, Yue, Ming Liu, openembedded-core
On Tue, Jan 26, 2016 at 11:12 PM, Ming Liu <liu.ming50@gmail.com> wrote:
>
>
> On 01/22/2016 09:39 PM, Bruce Ashfield wrote:
>>
>> On 16-01-20 6:29 PM, Ming Liu wrote:
>>>
>>>
>>>
>>> On 01/20/2016 05:43 AM, Bruce Ashfield wrote:
>>>>
>>>> On 2016-01-19 4:57 PM, Ming Liu wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 01/19/2016 08:39 PM, Bruce Ashfield wrote:
>>>>>>
>>>>>> On 16-01-05 08:12 AM, Ming Liu wrote:
>>>>>>>
>>>>>>> From: Ming Liu <peter.x.liu@external.atlascopco.com>
>>>>>>>
>>>>>>> It makes no sense to install a initramfs bundled kernel image since
>>>>>>> do_package does not depend on do_bundle_initramfs at all,
>>>>>>> otherwise, it
>>>>>>> leads to a implicit kernel-image package depending on do_package run
>>>>>>> before
>>>>>>> or after do_bundle_initramfs.
>>>>>>
>>>>>>
>>>>>> Again. So why not just add the ordering in the task dependencies ?
>>>>>
>>>>> If we add a intertask dependency like:
>>>>> add bundle_initramfs before do_install after do_deploy do_package
>>>>>
>>>>> Then it will somehow introduce a circular dependency as I described in
>>>>> another mail.
>>>>>>
>>>>>>
>>>>>> I'm probably missing something, which just means we need to tweak
>>>>>> the commit log a bit more.
>>>>>
>>>>> Maybe I should add some description in commit log about why I think we
>>>>> could not introduce a intertask dependency as a fix.
>>>>>
>>>>
>>>> That would be ideal, the more information the better.
>>>>
>>>>>>
>>>>>> The code you are removing is conditional, and is run after an
>>>>>> explicit kernel_do_compile is called, to rebuild the existing
>>>>>> kernel configuration with an embedded initramfs (via alternate
>>>>>> initrd).
>>>>>> So outside of some ordering/parallel execution issues, I'm not seeing
>>>>>> it as broken.
>>>>>
>>>>> Yes, I agree, it will not break the kernel re-compiling, the problem I
>>>>> want to fix here is just that it does not provide a certain way that we
>>>>> could add initramfs bundled kernel image into a rootfs.
>>>>>
>>>>
>>>> Speaking of breaking. What happens to existing users of INITRAMFS_IMAGE?
>>>> Do their existing image types and bundling continue to work without
>>>> modification ?
>>>
>>> That depends, the existing users always can find the INITRAMFS_IMAGE
>>> bundled kernel in DEPLOY_DIR with or without my patches, it is not
>>> broken. But if they want it installed in the rootfs, for some reasons,
>>> they will have the problem, like in my company, we want to boot the
>>> kernel from /boot/ on a USB disk, but it is not guaranteed we will get
>>> the INITRAMFS_IMAGE bundled kernel there during the build.
>>
>>
>> Right. And if someone isn't doing any initramfs bundling, is there
>> any impact ? No variables to change, etc ?
>
> Would not impact, no need to change any variables.
>
>>
>> I'd suggest double checking meta-initramfs:
>>
>>
>> http://layers.openembedded.org/layerindex/branch/master/layer/meta-initramfs/
>>
> OK, I will do that and let you know the results.
>
>> And checking with Andrea to be sure that none of the existing use
>> cases are broken.
>>
> OK, I will check with Andrea after I finished the tests with meta-initramfs
> layer.
>
>
> //Ming Liu
>>
>> Bruce
>>
>>>
>>> //Ming Liu
>>>>
>>>>
>>>> Bruce
>>>>
>>>>> //Ming Liu
>>>>>>
>>>>>>
>>>>>> Bruce
>>>>>>
>>>>>>>
>>>>>>> Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com>
>>>>>>> ---
>>>>>>> meta/classes/kernel.bbclass | 4 ----
>>>>>>> 1 file changed, 4 deletions(-)
>>>>>>>
>>>>>>> diff --git a/meta/classes/kernel.bbclass
>>>>>>> b/meta/classes/kernel.bbclass
>>>>>>> index 4ce1611..d1ca614 100644
>>>>>>> --- a/meta/classes/kernel.bbclass
>>>>>>> +++ b/meta/classes/kernel.bbclass
>>>>>>> @@ -179,10 +179,6 @@ do_bundle_initramfs () {
>>>>>>> kernel_do_compile
>>>>>>> mv -f ${KERNEL_OUTPUT} ${KERNEL_OUTPUT}.initramfs
>>>>>>> mv -f ${KERNEL_OUTPUT}.bak ${KERNEL_OUTPUT}
>>>>>>> - # Update install area
>>>>>>> - echo "There is kernel image bundled with initramfs:
>>>>>>> ${B}/${KERNEL_OUTPUT}.initramfs"
>>>>>>> - install -m 0644 ${B}/${KERNEL_OUTPUT}.initramfs
>>>>>>> ${D}/boot/${KERNEL_IMAGETYPE}-initramfs-${MACHINE}.bin
>>>>>>> - echo "${B}/${KERNEL_OUTPUT}.initramfs"
>>>>>>> fi
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Hi,
I could not yet test the proposed changes.
For a quick test please do build initramfs-kexecboot-klibc-image for qemu.
Thanks
Andrea
P.S. We did restore the old documentation about plain embedded
initramfs, pls have a look at the (outdated) msg:
https://github.com/kexecboot/kexecboot/wiki/oe-yocto
^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH 2/3] image.bbclass: removes bundle_initramfs related code
2016-01-05 13:12 [PATCH 0/3] Introduces kernel-initramfs recipe to resolve a implicit dependency issue Ming Liu
2016-01-05 13:12 ` [PATCH 1/3] kernel.bbclass: do not install initramfs bundled kernel image Ming Liu
@ 2016-01-05 13:12 ` Ming Liu
2016-01-05 13:12 ` [PATCH 3/3] kernel-initramfs: new recipe, creates initramfs bundled kernel packaging Ming Liu
` (2 subsequent siblings)
4 siblings, 0 replies; 17+ messages in thread
From: Ming Liu @ 2016-01-05 13:12 UTC (permalink / raw)
To: openembedded-core; +Cc: bruce.ashfield, yue.tao, Ming Liu
From: Ming Liu <peter.x.liu@external.atlascopco.com>
The original purpose of these code is to repackage initramfs bundled kernel
into rootfs by making image.bbclass build depend on bundle_initramfs of
virtual/kernel. But this is not going to succeed because virtual/kernel's
do_package is not depending on its bundle_initramfs.
We must figure out another way to package initramfs bundled kernel.
Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com>
---
meta/classes/image.bbclass | 11 -----------
1 file changed, 11 deletions(-)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index d2f8105..d87977c 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -181,9 +181,6 @@ python () {
check_image_features(d)
initramfs_image = d.getVar('INITRAMFS_IMAGE', True) or ""
- if initramfs_image != "":
- d.appendVarFlag('do_build', 'depends', " %s:do_bundle_initramfs" % d.getVar('PN', True))
- d.appendVarFlag('do_bundle_initramfs', 'depends', " %s:do_rootfs" % initramfs_image)
}
IMAGE_CLASSES += "image_types"
@@ -521,11 +518,3 @@ do_package_write_deb[noexec] = "1"
do_package_write_rpm[noexec] = "1"
addtask rootfs before do_build
-# Allow the kernel to be repacked with the initramfs and boot image file as a single file
-do_bundle_initramfs[depends] += "virtual/kernel:do_bundle_initramfs"
-do_bundle_initramfs[nostamp] = "1"
-do_bundle_initramfs[noexec] = "1"
-do_bundle_initramfs () {
- :
-}
-addtask bundle_initramfs after do_rootfs
--
1.9.1
^ permalink raw reply related [flat|nested] 17+ messages in thread* [PATCH 3/3] kernel-initramfs: new recipe, creates initramfs bundled kernel packaging
2016-01-05 13:12 [PATCH 0/3] Introduces kernel-initramfs recipe to resolve a implicit dependency issue Ming Liu
2016-01-05 13:12 ` [PATCH 1/3] kernel.bbclass: do not install initramfs bundled kernel image Ming Liu
2016-01-05 13:12 ` [PATCH 2/3] image.bbclass: removes bundle_initramfs related code Ming Liu
@ 2016-01-05 13:12 ` Ming Liu
2016-01-14 17:06 ` [PATCH 0/3] Introduces kernel-initramfs recipe to resolve a implicit dependency issue Bruce Ashfield
2016-01-19 19:34 ` Bruce Ashfield
4 siblings, 0 replies; 17+ messages in thread
From: Ming Liu @ 2016-01-05 13:12 UTC (permalink / raw)
To: openembedded-core; +Cc: bruce.ashfield, yue.tao, Ming Liu
From: Ming Liu <peter.x.liu@external.atlascopco.com>
So far, there is not a workable way to package the initramfs bundled kernel
image, the only place is tmp/deploy from where we could get it, but if a
user want to add it into a certain image, there is no guarantee that he
will achieve it because a explicit dependency is missing between package
and bundle_initramfs, and this was designed to avoid introducing circular
dependencies when using kernel modules in the initramfs image.bb that is
caused by kernel.bbclass trying to build the initramfs before the kernel
packaging.
To fix this problem, the idea is to split the initramfs bundled kernel
packaging to a new recipe, make the do_install depend on kernel's deploy
task, then with the following config:
IMAGE_INSTALL_append = " kernel-initramfs"
The initramfs bundled kernel could be added to the image without
introducing any circular dependencies.
Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com>
---
meta/recipes-kernel/linux/kernel-initramfs.bb | 69 +++++++++++++++++++++++++++
1 file changed, 69 insertions(+)
create mode 100644 meta/recipes-kernel/linux/kernel-initramfs.bb
diff --git a/meta/recipes-kernel/linux/kernel-initramfs.bb b/meta/recipes-kernel/linux/kernel-initramfs.bb
new file mode 100644
index 0000000..7f9d72b
--- /dev/null
+++ b/meta/recipes-kernel/linux/kernel-initramfs.bb
@@ -0,0 +1,69 @@
+SUMMARY = "Initramfs bundled kernel image"
+DESCRIPTION = "When built, it packages a initramfs bundled kernel image of the \
+preferred virtual/kernel provider."
+
+SECTION = "kernel"
+
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "[file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6]file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6"
+
+inherit linux-kernel-base
+
+# Whilst not a module, this ensures we don't get multilib extended. (which would make no sense)
+inherit module-base
+
+S = "${STAGING_KERNEL_DIR}"
+B = "${WORKDIR}/build"
+
+# we dont need the default dependencies.
+INHIBIT_DEFAULT_DEPS = "1"
+
+KERNEL_IMAGETYPE ?= "zImage"
+KERNEL_VERSION = "${@get_kernelversion_file('${STAGING_KERNEL_BUILDDIR}')}"
+KERNEL_IMAGEDEST = "boot"
+
+KERNEL_PRIORITY ?= "${@int(d.getVar('KERNEL_VERSION',1).split('-')[0].split('+')[0].split('.')[0]) * 10000 + \
+ int(d.getVar('KERNEL_VERSION',1).split('-')[0].split('+')[0].split('.')[1]) * 100 + \
+ int(d.getVar('KERNEL_VERSION',1).split('-')[0].split('+')[0].split('.')[-1])}"
+
+PACKAGES = "${PN}"
+FILES_${PN} = "/${KERNEL_IMAGEDEST}/${KERNEL_IMAGETYPE}*"
+
+PKG_${PN} = "${PN}-${@legitimize_package_name('${KERNEL_VERSION}')}"
+
+PACKAGE_ARCH = "${MACHINE_ARCH}"
+
+# Skip processing of this recipe if INITRAMFS_IMAGE or INITRAMFS_IMAGE_BUNDLE
+# is not set correctly, to avoid generate a single empty package which makes
+# no sense.
+python __anonymous () {
+ if not d.getVar('INITRAMFS_IMAGE', True) or d.getVar('INITRAMFS_IMAGE_BUNDLE', True) != '1':
+ raise bb.parse.SkipPackage("Set INITRAMFS_IMAGE and INITRAMFS_IMAGE_BUNDLE to enable it")
+}
+
+# Need the output of deploy.
+do_install[depends] += "virtual/kernel:do_deploy"
+
+# We only need the packaging tasks - disable the rest
+do_fetch[noexec] = "1"
+do_unpack[noexec] = "1"
+do_patch[noexec] = "1"
+do_configure[noexec] = "1"
+do_compile[noexec] = "1"
+do_populate_sysroot[noexec] = "1"
+
+do_install() {
+ if [ ! -z "${INITRAMFS_IMAGE}" -a x"${INITRAMFS_IMAGE_BUNDLE}" = x1 ]; then
+ echo "Copying initramfs bundled kernel image from ${DEPLOY_DIR_IMAGE}..."
+ install -d ${D}/${KERNEL_IMAGEDEST}
+ install -m 0644 ${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE}-initramfs-${MACHINE}.bin ${D}/${KERNEL_IMAGEDEST}/${KERNEL_IMAGETYPE}-initramfs-${KERNEL_VERSION}
+ fi
+}
+
+pkg_postinst_${PN} () {
+ update-alternatives --install /${KERNEL_IMAGEDEST}/${KERNEL_IMAGETYPE}-initramfs ${KERNEL_IMAGETYPE}-initramfs /${KERNEL_IMAGEDEST}/${KERNEL_IMAGETYPE}-initramfs-${KERNEL_VERSION} ${KERNEL_PRIORITY} || true
+}
+
+pkg_postrm_${PN} () {
+ update-alternatives --remove ${KERNEL_IMAGETYPE}-initramfs ${KERNEL_IMAGETYPE}-initramfs-${KERNEL_VERSION} || true
+}
--
1.9.1
^ permalink raw reply related [flat|nested] 17+ messages in thread* Re: [PATCH 0/3] Introduces kernel-initramfs recipe to resolve a implicit dependency issue
2016-01-05 13:12 [PATCH 0/3] Introduces kernel-initramfs recipe to resolve a implicit dependency issue Ming Liu
` (2 preceding siblings ...)
2016-01-05 13:12 ` [PATCH 3/3] kernel-initramfs: new recipe, creates initramfs bundled kernel packaging Ming Liu
@ 2016-01-14 17:06 ` Bruce Ashfield
2016-01-15 8:46 ` Ming Liu
2016-01-19 19:34 ` Bruce Ashfield
4 siblings, 1 reply; 17+ messages in thread
From: Bruce Ashfield @ 2016-01-14 17:06 UTC (permalink / raw)
To: Ming Liu, openembedded-core; +Cc: yue.tao
Just bumping this review to let you know that I haven't forgotten
about it.
I've been looking at the details at least twice now, but haven't
managed to sort everything out.
I'll pick this up again shortly.
Bruce
On 16-01-05 08:12 AM, Ming Liu wrote:
> In current initramfs bundled kernel packaging policy, there are several
> dependency chains co-existing:
>
> | "core-image-minimal.do_build" -> "core-image-minimal.do_bundle_initramfs"
> | "core-image-minimal.do_bundle_initramfs" -> "virtual/kernel.do_bundle_initramfs"
> | "core-image-minimal.do_bundle_initramfs" -> "core-image-minimal.do_rootfs"
> | "core-image-minimal.do_rootfs" -> "virtual/kernel.do_package_write_${IMAGE_PKGTYPE}"
> | "virtual/kernel.do_package_write_${IMAGE_PKGTYPE}" -> "virtual/kernel.do_package"
> | "virtual/kernel.do_package" -> "virtual/kernel.do_install"
> |
> | "virtual/kernel.do_deploy" -> "virtual/kernel.do_bundle_initramfs"
> | "virtual/kernel.do_bundle_initramfs" -> "virtual/kernel.do_install"
>
> We could see, virtual/kernel.do_package is not explicitly depending on
> virtual/kernel.do_bundle_initramfs so far, therefore, there is not a
> workable way to add initramfs bundled kernel image into rootfs, because
> kernel's do_bundle_initramfs could run parallelly with its do_package,
> which means we will get a implicit kernel-image package that sometimes it
> contains the initramfs bundled kernel or sometimes it doesn't.
>
> To fix this problem, the idea is to let the initramfs bundled kernel
> packaging depend on do_bundle_initramfs, meanwhile, to avoid the circular
> dependency issue that commit: 609d5a9ab9e58bb1c2bcc2145399fbc8b701b85a
> [ kernel.bbclass, image.bbclass: Implement kernel INITRAMFS dependency and bundling ]
>
> was trying to address, this dependency has to be splitted from kernel
> recipe(at least, I could not figure out another way to achieve it), so a
> new kernel-initramfs is introduced, in which a dependency chain is created:
>
> | "kernel-initramfs.do_install" -> "virtual/kernel.do_deploy"
> | "virtual/kernel.do_deploy" -> "virtual/kernel.do_bundle_initramfs"
>
> Then the users can add initramfs bundled kernel image into rootfs by:
>
> IMAGE_INSTALL_append = " kernel-initramfs"
>
> without introducing any circular dependencies.
>
> Ming Liu (3):
> kernel.bbclass: do not install initramfs bundled kernel image
> image.bbclass: removes bundle_initramfs related code
> kernel-initramfs: new recipe, creates initramfs bundled kernel
> packaging
>
> meta/classes/image.bbclass | 11 -----
> meta/classes/kernel.bbclass | 4 --
> meta/recipes-kernel/linux/kernel-initramfs.bb | 69 +++++++++++++++++++++++++++
> 3 files changed, 69 insertions(+), 15 deletions(-)
> create mode 100644 meta/recipes-kernel/linux/kernel-initramfs.bb
>
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 0/3] Introduces kernel-initramfs recipe to resolve a implicit dependency issue
2016-01-14 17:06 ` [PATCH 0/3] Introduces kernel-initramfs recipe to resolve a implicit dependency issue Bruce Ashfield
@ 2016-01-15 8:46 ` Ming Liu
0 siblings, 0 replies; 17+ messages in thread
From: Ming Liu @ 2016-01-15 8:46 UTC (permalink / raw)
To: Bruce Ashfield; +Cc: yue.tao, OE-core
[-- Attachment #1: Type: text/plain, Size: 3161 bytes --]
Hi, Bruce:
No problem, thanks for letting me know the status.
//Ming Liu
2016-01-14 18:06 GMT+01:00 Bruce Ashfield <bruce.ashfield@windriver.com>:
> Just bumping this review to let you know that I haven't forgotten
> about it.
>
> I've been looking at the details at least twice now, but haven't
> managed to sort everything out.
>
> I'll pick this up again shortly.
>
> Bruce
>
>
> On 16-01-05 08:12 AM, Ming Liu wrote:
>
>> In current initramfs bundled kernel packaging policy, there are several
>> dependency chains co-existing:
>>
>> | "core-image-minimal.do_build" ->
>> "core-image-minimal.do_bundle_initramfs"
>> | "core-image-minimal.do_bundle_initramfs" ->
>> "virtual/kernel.do_bundle_initramfs"
>> | "core-image-minimal.do_bundle_initramfs" ->
>> "core-image-minimal.do_rootfs"
>> | "core-image-minimal.do_rootfs" ->
>> "virtual/kernel.do_package_write_${IMAGE_PKGTYPE}"
>> | "virtual/kernel.do_package_write_${IMAGE_PKGTYPE}" ->
>> "virtual/kernel.do_package"
>> | "virtual/kernel.do_package" -> "virtual/kernel.do_install"
>> |
>> | "virtual/kernel.do_deploy" -> "virtual/kernel.do_bundle_initramfs"
>> | "virtual/kernel.do_bundle_initramfs" -> "virtual/kernel.do_install"
>>
>> We could see, virtual/kernel.do_package is not explicitly depending on
>> virtual/kernel.do_bundle_initramfs so far, therefore, there is not a
>> workable way to add initramfs bundled kernel image into rootfs, because
>> kernel's do_bundle_initramfs could run parallelly with its do_package,
>> which means we will get a implicit kernel-image package that sometimes it
>> contains the initramfs bundled kernel or sometimes it doesn't.
>>
>> To fix this problem, the idea is to let the initramfs bundled kernel
>> packaging depend on do_bundle_initramfs, meanwhile, to avoid the circular
>> dependency issue that commit: 609d5a9ab9e58bb1c2bcc2145399fbc8b701b85a
>> [ kernel.bbclass, image.bbclass: Implement kernel INITRAMFS dependency
>> and bundling ]
>>
>> was trying to address, this dependency has to be splitted from kernel
>> recipe(at least, I could not figure out another way to achieve it), so a
>> new kernel-initramfs is introduced, in which a dependency chain is
>> created:
>>
>> | "kernel-initramfs.do_install" -> "virtual/kernel.do_deploy"
>> | "virtual/kernel.do_deploy" -> "virtual/kernel.do_bundle_initramfs"
>>
>> Then the users can add initramfs bundled kernel image into rootfs by:
>>
>> IMAGE_INSTALL_append = " kernel-initramfs"
>>
>> without introducing any circular dependencies.
>>
>> Ming Liu (3):
>> kernel.bbclass: do not install initramfs bundled kernel image
>> image.bbclass: removes bundle_initramfs related code
>> kernel-initramfs: new recipe, creates initramfs bundled kernel
>> packaging
>>
>> meta/classes/image.bbclass | 11 -----
>> meta/classes/kernel.bbclass | 4 --
>> meta/recipes-kernel/linux/kernel-initramfs.bb | 69
>> +++++++++++++++++++++++++++
>> 3 files changed, 69 insertions(+), 15 deletions(-)
>> create mode 100644 meta/recipes-kernel/linux/kernel-initramfs.bb
>>
>>
>
[-- Attachment #2: Type: text/html, Size: 4213 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 0/3] Introduces kernel-initramfs recipe to resolve a implicit dependency issue
2016-01-05 13:12 [PATCH 0/3] Introduces kernel-initramfs recipe to resolve a implicit dependency issue Ming Liu
` (3 preceding siblings ...)
2016-01-14 17:06 ` [PATCH 0/3] Introduces kernel-initramfs recipe to resolve a implicit dependency issue Bruce Ashfield
@ 2016-01-19 19:34 ` Bruce Ashfield
2016-01-19 21:37 ` Ming Liu
4 siblings, 1 reply; 17+ messages in thread
From: Bruce Ashfield @ 2016-01-19 19:34 UTC (permalink / raw)
To: Ming Liu, openembedded-core; +Cc: yue.tao
On 16-01-05 08:12 AM, Ming Liu wrote:
> In current initramfs bundled kernel packaging policy, there are several
> dependency chains co-existing:
>
> | "core-image-minimal.do_build" -> "core-image-minimal.do_bundle_initramfs"
> | "core-image-minimal.do_bundle_initramfs" -> "virtual/kernel.do_bundle_initramfs"
> | "core-image-minimal.do_bundle_initramfs" -> "core-image-minimal.do_rootfs"
In current master, the above dependency should now be
do_image_complete, correct ?
> | "core-image-minimal.do_rootfs" -> "virtual/kernel.do_package_write_${IMAGE_PKGTYPE}"
And for the one above here, I'm not seeing this dependency. Are you
saying that it comes via the do_image_complete dependency ?
> | "virtual/kernel.do_package_write_${IMAGE_PKGTYPE}" -> "virtual/kernel.do_package"
> | "virtual/kernel.do_package" -> "virtual/kernel.do_install"
> |
> | "virtual/kernel.do_deploy" -> "virtual/kernel.do_bundle_initramfs"
> | "virtual/kernel.do_bundle_initramfs" -> "virtual/kernel.do_install"
I'm somehow missing the above dependency as well. I suppose I could dump
out the dot file, but I'd like to hear it explained here as well. Since
if I can't get the dependency from the text of the commits, it will
become hard to maintain.
>
> We could see, virtual/kernel.do_package is not explicitly depending on
> virtual/kernel.do_bundle_initramfs so far, therefore, there is not a
> workable way to add initramfs bundled kernel image into rootfs, because
> kernel's do_bundle_initramfs could run parallelly with its do_package,
> which means we will get a implicit kernel-image package that sometimes it
> contains the initramfs bundled kernel or sometimes it doesn't.
I do see what you are describing above. If we've defined
INITRAMFS_IMAGE, the anonymous python in kernel.bbclass does make
the kernel's do_bundle_initramfs depend on the initramfs image's
do_image_complete.
Why not just add a task dependency ?
>
> To fix this problem, the idea is to let the initramfs bundled kernel
> packaging depend on do_bundle_initramfs, meanwhile, to avoid the circular
> dependency issue that commit: 609d5a9ab9e58bb1c2bcc2145399fbc8b701b85a
> [ kernel.bbclass, image.bbclass: Implement kernel INITRAMFS dependency and bundling ]
But here's my issue. We know that the INITRAMFS image cannot contain,
or depend on a kernel itself. So the dependency won't be circular.
It is true that we don't enforce that, but that has always been stated
in the commits that created the bundling.
Is it that condition you are trying to enforce with the split ?
Bruce
>
> was trying to address, this dependency has to be splitted from kernel
> recipe(at least, I could not figure out another way to achieve it), so a
> new kernel-initramfs is introduced, in which a dependency chain is created:
>
> | "kernel-initramfs.do_install" -> "virtual/kernel.do_deploy"
> | "virtual/kernel.do_deploy" -> "virtual/kernel.do_bundle_initramfs"
>
> Then the users can add initramfs bundled kernel image into rootfs by:
>
> IMAGE_INSTALL_append = " kernel-initramfs"
>
> without introducing any circular dependencies.
>
> Ming Liu (3):
> kernel.bbclass: do not install initramfs bundled kernel image
> image.bbclass: removes bundle_initramfs related code
> kernel-initramfs: new recipe, creates initramfs bundled kernel
> packaging
>
> meta/classes/image.bbclass | 11 -----
> meta/classes/kernel.bbclass | 4 --
> meta/recipes-kernel/linux/kernel-initramfs.bb | 69 +++++++++++++++++++++++++++
> 3 files changed, 69 insertions(+), 15 deletions(-)
> create mode 100644 meta/recipes-kernel/linux/kernel-initramfs.bb
>
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 0/3] Introduces kernel-initramfs recipe to resolve a implicit dependency issue
2016-01-19 19:34 ` Bruce Ashfield
@ 2016-01-19 21:37 ` Ming Liu
2016-01-19 22:03 ` Ming Liu
2016-01-20 5:03 ` Bruce Ashfield
0 siblings, 2 replies; 17+ messages in thread
From: Ming Liu @ 2016-01-19 21:37 UTC (permalink / raw)
To: Bruce Ashfield, openembedded-core; +Cc: yue.tao
On 01/19/2016 08:34 PM, Bruce Ashfield wrote:
> On 16-01-05 08:12 AM, Ming Liu wrote:
>> In current initramfs bundled kernel packaging policy, there are several
>> dependency chains co-existing:
>>
>> | "core-image-minimal.do_build" ->
>> "core-image-minimal.do_bundle_initramfs"
>> | "core-image-minimal.do_bundle_initramfs" ->
>> "virtual/kernel.do_bundle_initramfs"
>> | "core-image-minimal.do_bundle_initramfs" ->
>> "core-image-minimal.do_rootfs"
>
> In current master, the above dependency should now be
> do_image_complete, correct ?
Yes, now it has been changed to do_image_complete.
>
>> | "core-image-minimal.do_rootfs" ->
>> "virtual/kernel.do_package_write_${IMAGE_PKGTYPE}"
>
> And for the one above here, I'm not seeing this dependency. Are you
> saying that it comes via the do_image_complete dependency ?
It comes from the "recrdeptask" flag in image bbclass, for instance,
meta/classes/rootfs_rpm.bbclass, it has:
do_rootfs[recrdeptask] += "do_package_write_rpm"
this makes sure that do_rootfs task of a certain image would run after
do_package_write_rpm of all its DEPENDS and RDEPENDS, recursively.
>
>> | "virtual/kernel.do_package_write_${IMAGE_PKGTYPE}" ->
>> "virtual/kernel.do_package"
>> | "virtual/kernel.do_package" -> "virtual/kernel.do_install"
>> |
>> | "virtual/kernel.do_deploy" -> "virtual/kernel.do_bundle_initramfs"
>> | "virtual/kernel.do_bundle_initramfs" -> "virtual/kernel.do_install"
>
> I'm somehow missing the above dependency as well. I suppose I could dump
> out the dot file, but I'd like to hear it explained here as well. Since
> if I can't get the dependency from the text of the commits, it will
> become hard to maintain.
They are intertask dependencies, I still take RPM as a example:
meta/classes/package_rpm.bbclass:addtask package_write_rpm after
do_packagedata do_package
meta/classes/kernel.bbclass:addtask bundle_initramfs after do_install
before do_deploy
>
>>
>> We could see, virtual/kernel.do_package is not explicitly depending on
>> virtual/kernel.do_bundle_initramfs so far, therefore, there is not a
>> workable way to add initramfs bundled kernel image into rootfs, because
>> kernel's do_bundle_initramfs could run parallelly with its do_package,
>> which means we will get a implicit kernel-image package that
>> sometimes it
>> contains the initramfs bundled kernel or sometimes it doesn't.
>
> I do see what you are describing above. If we've defined
> INITRAMFS_IMAGE, the anonymous python in kernel.bbclass does make
> the kernel's do_bundle_initramfs depend on the initramfs image's
> do_image_complete.
>
> Why not just add a task dependency ?
Do you mean adding a task dependency between package and
bundle_initramfs in kernel recipe? But that would introduce a circular
dependency issue as described in commit log of
609d5a9ab9e58bb1c2bcc2145399fbc8b701b85a, under following conditions:
1 Some kernel modules have been added into INITRAMFS_IMAGE.
2 INITRAMFS_IMAGE has been bundled into kernel image
3 kernel-image package has been added into IMAGE_INSTALL.
>
>>
>> To fix this problem, the idea is to let the initramfs bundled kernel
>> packaging depend on do_bundle_initramfs, meanwhile, to avoid the circular
>> dependency issue that commit: 609d5a9ab9e58bb1c2bcc2145399fbc8b701b85a
>> [ kernel.bbclass, image.bbclass: Implement kernel INITRAMFS
>> dependency and bundling ]
>
> But here's my issue. We know that the INITRAMFS image cannot contain,
> or depend on a kernel itself. So the dependency won't be circular.
> It is true that we don't enforce that, but that has always been stated
> in the commits that created the bundling.
>
> Is it that condition you are trying to enforce with the split ?
I know that the users are not allowed to add kernel itself into a
INITRAMFS_IMAGE meanwhile bundle it into kernel, which will certainly
create a circular dependency. The split was not trying to resolve that
condition, but to fix a implicit kernel-image package without
introducing any circular dependencies.
//Ming Liu
>
> Bruce
>
>>
>> was trying to address, this dependency has to be splitted from kernel
>> recipe(at least, I could not figure out another way to achieve it), so a
>> new kernel-initramfs is introduced, in which a dependency chain is
>> created:
>>
>> | "kernel-initramfs.do_install" -> "virtual/kernel.do_deploy"
>> | "virtual/kernel.do_deploy" -> "virtual/kernel.do_bundle_initramfs"
>>
>> Then the users can add initramfs bundled kernel image into rootfs by:
>>
>> IMAGE_INSTALL_append = " kernel-initramfs"
>>
>> without introducing any circular dependencies.
>>
>> Ming Liu (3):
>> kernel.bbclass: do not install initramfs bundled kernel image
>> image.bbclass: removes bundle_initramfs related code
>> kernel-initramfs: new recipe, creates initramfs bundled kernel
>> packaging
>>
>> meta/classes/image.bbclass | 11 -----
>> meta/classes/kernel.bbclass | 4 --
>> meta/recipes-kernel/linux/kernel-initramfs.bb | 69
>> +++++++++++++++++++++++++++
>> 3 files changed, 69 insertions(+), 15 deletions(-)
>> create mode 100644 meta/recipes-kernel/linux/kernel-initramfs.bb
>>
>
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 0/3] Introduces kernel-initramfs recipe to resolve a implicit dependency issue
2016-01-19 21:37 ` Ming Liu
@ 2016-01-19 22:03 ` Ming Liu
2016-01-20 5:03 ` Bruce Ashfield
1 sibling, 0 replies; 17+ messages in thread
From: Ming Liu @ 2016-01-19 22:03 UTC (permalink / raw)
To: Bruce Ashfield, openembedded-core; +Cc: yue.tao
On 01/19/2016 10:37 PM, Ming Liu wrote:
>
>
> On 01/19/2016 08:34 PM, Bruce Ashfield wrote:
>> On 16-01-05 08:12 AM, Ming Liu wrote:
>>> In current initramfs bundled kernel packaging policy, there are several
>>> dependency chains co-existing:
>>>
>>> | "core-image-minimal.do_build" ->
>>> "core-image-minimal.do_bundle_initramfs"
>>> | "core-image-minimal.do_bundle_initramfs" ->
>>> "virtual/kernel.do_bundle_initramfs"
>>> | "core-image-minimal.do_bundle_initramfs" ->
>>> "core-image-minimal.do_rootfs"
>>
>> In current master, the above dependency should now be
>> do_image_complete, correct ?
> Yes, now it has been changed to do_image_complete.
>
>>
>>> | "core-image-minimal.do_rootfs" ->
>>> "virtual/kernel.do_package_write_${IMAGE_PKGTYPE}"
>>
>> And for the one above here, I'm not seeing this dependency. Are you
>> saying that it comes via the do_image_complete dependency ?
> It comes from the "recrdeptask" flag in image bbclass, for instance,
> meta/classes/rootfs_rpm.bbclass, it has:
> do_rootfs[recrdeptask] += "do_package_write_rpm"
>
> this makes sure that do_rootfs task of a certain image would run after
> do_package_write_rpm of all its DEPENDS and RDEPENDS, recursively.
>
>>
>>> | "virtual/kernel.do_package_write_${IMAGE_PKGTYPE}" ->
>>> "virtual/kernel.do_package"
>>> | "virtual/kernel.do_package" -> "virtual/kernel.do_install"
>>> |
>>> | "virtual/kernel.do_deploy" -> "virtual/kernel.do_bundle_initramfs"
>>> | "virtual/kernel.do_bundle_initramfs" -> "virtual/kernel.do_install"
>>
>> I'm somehow missing the above dependency as well. I suppose I could dump
>> out the dot file, but I'd like to hear it explained here as well. Since
>> if I can't get the dependency from the text of the commits, it will
>> become hard to maintain.
> They are intertask dependencies, I still take RPM as a example:
> meta/classes/package_rpm.bbclass:addtask package_write_rpm after
> do_packagedata do_package
> meta/classes/kernel.bbclass:addtask bundle_initramfs after do_install
> before do_deploy
>
>>
>>>
>>> We could see, virtual/kernel.do_package is not explicitly depending on
>>> virtual/kernel.do_bundle_initramfs so far, therefore, there is not a
>>> workable way to add initramfs bundled kernel image into rootfs, because
>>> kernel's do_bundle_initramfs could run parallelly with its do_package,
>>> which means we will get a implicit kernel-image package that
>>> sometimes it
>>> contains the initramfs bundled kernel or sometimes it doesn't.
>>
>> I do see what you are describing above. If we've defined
>> INITRAMFS_IMAGE, the anonymous python in kernel.bbclass does make
>> the kernel's do_bundle_initramfs depend on the initramfs image's
>> do_image_complete.
>>
>> Why not just add a task dependency ?
> Do you mean adding a task dependency between package and
> bundle_initramfs in kernel recipe? But that would introduce a circular
> dependency issue as described in commit log of
> 609d5a9ab9e58bb1c2bcc2145399fbc8b701b85a, under following conditions:
> 1 Some kernel modules have been added into INITRAMFS_IMAGE.
> 2 INITRAMFS_IMAGE has been bundled into kernel image
> 3 kernel-image package has been added into IMAGE_INSTALL.
Here, I mean the IMAGE_INSTALL of a normal image like core-image-minimal.
//Ming Liu
>
>>
>>>
>>> To fix this problem, the idea is to let the initramfs bundled kernel
>>> packaging depend on do_bundle_initramfs, meanwhile, to avoid the
>>> circular
>>> dependency issue that commit: 609d5a9ab9e58bb1c2bcc2145399fbc8b701b85a
>>> [ kernel.bbclass, image.bbclass: Implement kernel INITRAMFS
>>> dependency and bundling ]
>>
>> But here's my issue. We know that the INITRAMFS image cannot contain,
>> or depend on a kernel itself. So the dependency won't be circular.
>> It is true that we don't enforce that, but that has always been stated
>> in the commits that created the bundling.
>>
>> Is it that condition you are trying to enforce with the split ?
> I know that the users are not allowed to add kernel itself into a
> INITRAMFS_IMAGE meanwhile bundle it into kernel, which will certainly
> create a circular dependency. The split was not trying to resolve that
> condition, but to fix a implicit kernel-image package without
> introducing any circular dependencies.
>
> //Ming Liu
>>
>> Bruce
>>
>>>
>>> was trying to address, this dependency has to be splitted from kernel
>>> recipe(at least, I could not figure out another way to achieve it),
>>> so a
>>> new kernel-initramfs is introduced, in which a dependency chain is
>>> created:
>>>
>>> | "kernel-initramfs.do_install" -> "virtual/kernel.do_deploy"
>>> | "virtual/kernel.do_deploy" -> "virtual/kernel.do_bundle_initramfs"
>>>
>>> Then the users can add initramfs bundled kernel image into rootfs by:
>>>
>>> IMAGE_INSTALL_append = " kernel-initramfs"
>>>
>>> without introducing any circular dependencies.
>>>
>>> Ming Liu (3):
>>> kernel.bbclass: do not install initramfs bundled kernel image
>>> image.bbclass: removes bundle_initramfs related code
>>> kernel-initramfs: new recipe, creates initramfs bundled kernel
>>> packaging
>>>
>>> meta/classes/image.bbclass | 11 -----
>>> meta/classes/kernel.bbclass | 4 --
>>> meta/recipes-kernel/linux/kernel-initramfs.bb | 69
>>> +++++++++++++++++++++++++++
>>> 3 files changed, 69 insertions(+), 15 deletions(-)
>>> create mode 100644 meta/recipes-kernel/linux/kernel-initramfs.bb
>>>
>>
>
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 0/3] Introduces kernel-initramfs recipe to resolve a implicit dependency issue
2016-01-19 21:37 ` Ming Liu
2016-01-19 22:03 ` Ming Liu
@ 2016-01-20 5:03 ` Bruce Ashfield
1 sibling, 0 replies; 17+ messages in thread
From: Bruce Ashfield @ 2016-01-20 5:03 UTC (permalink / raw)
To: Ming Liu, openembedded-core; +Cc: yue.tao
On 2016-01-19 4:37 PM, Ming Liu wrote:
>
>
> On 01/19/2016 08:34 PM, Bruce Ashfield wrote:
>> On 16-01-05 08:12 AM, Ming Liu wrote:
>>> In current initramfs bundled kernel packaging policy, there are several
>>> dependency chains co-existing:
>>>
>>> | "core-image-minimal.do_build" ->
>>> "core-image-minimal.do_bundle_initramfs"
>>> | "core-image-minimal.do_bundle_initramfs" ->
>>> "virtual/kernel.do_bundle_initramfs"
>>> | "core-image-minimal.do_bundle_initramfs" ->
>>> "core-image-minimal.do_rootfs"
>>
>> In current master, the above dependency should now be
>> do_image_complete, correct ?
> Yes, now it has been changed to do_image_complete.
>
>>
>>> | "core-image-minimal.do_rootfs" ->
>>> "virtual/kernel.do_package_write_${IMAGE_PKGTYPE}"
>>
>> And for the one above here, I'm not seeing this dependency. Are you
>> saying that it comes via the do_image_complete dependency ?
> It comes from the "recrdeptask" flag in image bbclass, for instance,
> meta/classes/rootfs_rpm.bbclass, it has:
> do_rootfs[recrdeptask] += "do_package_write_rpm"
>
> this makes sure that do_rootfs task of a certain image would run after
> do_package_write_rpm of all its DEPENDS and RDEPENDS, recursively.
>
>>
>>> | "virtual/kernel.do_package_write_${IMAGE_PKGTYPE}" ->
>>> "virtual/kernel.do_package"
>>> | "virtual/kernel.do_package" -> "virtual/kernel.do_install"
>>> |
>>> | "virtual/kernel.do_deploy" -> "virtual/kernel.do_bundle_initramfs"
>>> | "virtual/kernel.do_bundle_initramfs" -> "virtual/kernel.do_install"
>>
>> I'm somehow missing the above dependency as well. I suppose I could dump
>> out the dot file, but I'd like to hear it explained here as well. Since
>> if I can't get the dependency from the text of the commits, it will
>> become hard to maintain.
> They are intertask dependencies, I still take RPM as a example:
> meta/classes/package_rpm.bbclass:addtask package_write_rpm after
> do_packagedata do_package
> meta/classes/kernel.bbclass:addtask bundle_initramfs after do_install
> before do_deploy
>
>>
>>>
>>> We could see, virtual/kernel.do_package is not explicitly depending on
>>> virtual/kernel.do_bundle_initramfs so far, therefore, there is not a
>>> workable way to add initramfs bundled kernel image into rootfs, because
>>> kernel's do_bundle_initramfs could run parallelly with its do_package,
>>> which means we will get a implicit kernel-image package that
>>> sometimes it
>>> contains the initramfs bundled kernel or sometimes it doesn't.
>>
>> I do see what you are describing above. If we've defined
>> INITRAMFS_IMAGE, the anonymous python in kernel.bbclass does make
>> the kernel's do_bundle_initramfs depend on the initramfs image's
>> do_image_complete.
>>
>> Why not just add a task dependency ?
> Do you mean adding a task dependency between package and
As long as we've built the kernel + modules and also built the
initramfs image, we have everything we need to bundle the kernel and
initramfs.
.. but yes, if it wasn't package, it would have to be the compile
phase, and the circular dependency is the same.
> bundle_initramfs in kernel recipe? But that would introduce a circular
> dependency issue as described in commit log of
> 609d5a9ab9e58bb1c2bcc2145399fbc8b701b85a, under following conditions:
> 1 Some kernel modules have been added into INITRAMFS_IMAGE.
> 2 INITRAMFS_IMAGE has been bundled into kernel image
> 3 kernel-image package has been added into IMAGE_INSTALL.
>
Agreed.
>>
>>>
>>> To fix this problem, the idea is to let the initramfs bundled kernel
>>> packaging depend on do_bundle_initramfs, meanwhile, to avoid the
>>> circular
>>> dependency issue that commit: 609d5a9ab9e58bb1c2bcc2145399fbc8b701b85a
>>> [ kernel.bbclass, image.bbclass: Implement kernel INITRAMFS
>>> dependency and bundling ]
>>
>> But here's my issue. We know that the INITRAMFS image cannot contain,
>> or depend on a kernel itself. So the dependency won't be circular.
>> It is true that we don't enforce that, but that has always been stated
>> in the commits that created the bundling.
>>
>> Is it that condition you are trying to enforce with the split ?
> I know that the users are not allowed to add kernel itself into a
> INITRAMFS_IMAGE meanwhile bundle it into kernel, which will certainly
> create a circular dependency. The split was not trying to resolve that
> condition, but to fix a implicit kernel-image package without
> introducing any circular dependencies.
Right.
Bruce
>
> //Ming Liu
>>
>> Bruce
>>
>>>
>>> was trying to address, this dependency has to be splitted from kernel
>>> recipe(at least, I could not figure out another way to achieve it), so a
>>> new kernel-initramfs is introduced, in which a dependency chain is
>>> created:
>>>
>>> | "kernel-initramfs.do_install" -> "virtual/kernel.do_deploy"
>>> | "virtual/kernel.do_deploy" -> "virtual/kernel.do_bundle_initramfs"
>>>
>>> Then the users can add initramfs bundled kernel image into rootfs by:
>>>
>>> IMAGE_INSTALL_append = " kernel-initramfs"
>>>
>>> without introducing any circular dependencies.
>>>
>>> Ming Liu (3):
>>> kernel.bbclass: do not install initramfs bundled kernel image
>>> image.bbclass: removes bundle_initramfs related code
>>> kernel-initramfs: new recipe, creates initramfs bundled kernel
>>> packaging
>>>
>>> meta/classes/image.bbclass | 11 -----
>>> meta/classes/kernel.bbclass | 4 --
>>> meta/recipes-kernel/linux/kernel-initramfs.bb | 69
>>> +++++++++++++++++++++++++++
>>> 3 files changed, 69 insertions(+), 15 deletions(-)
>>> create mode 100644 meta/recipes-kernel/linux/kernel-initramfs.bb
>>>
>>
>
^ permalink raw reply [flat|nested] 17+ messages in thread