From: Ming Liu <liu.ming50@gmail.com>
To: Bruce Ashfield <bruce.ashfield@windriver.com>,
openembedded-core@lists.openembedded.org
Cc: "Tao, Yue" <Yue.Tao@windriver.com>,
Ming Liu <peter.x.liu@external.atlascopco.com>
Subject: Re: [PATCH 1/3] kernel.bbclass: do not install initramfs bundled kernel image
Date: Tue, 26 Jan 2016 23:12:53 +0100 [thread overview]
Message-ID: <56A7EF65.60909@gmail.com> (raw)
In-Reply-To: <56A29386.1090600@windriver.com>
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
>>>>>> }
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
next prev parent reply other threads:[~2016-01-26 22:12 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
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-19 19:39 ` Bruce Ashfield
2016-01-19 21:57 ` Ming Liu
2016-01-20 4:43 ` Bruce Ashfield
2016-01-20 23:29 ` Ming Liu
2016-01-22 20:39 ` Bruce Ashfield
2016-01-26 22:12 ` Ming Liu [this message]
2016-01-26 23:22 ` Andrea Adami
2016-01-05 13:12 ` [PATCH 2/3] image.bbclass: removes bundle_initramfs related code Ming Liu
2016-01-05 13:12 ` [PATCH 3/3] kernel-initramfs: new recipe, creates initramfs bundled kernel packaging Ming Liu
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
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56A7EF65.60909@gmail.com \
--to=liu.ming50@gmail.com \
--cc=Yue.Tao@windriver.com \
--cc=bruce.ashfield@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=peter.x.liu@external.atlascopco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox