All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ming Liu <liu.ming50@gmail.com>
To: Bruce Ashfield <bruce.ashfield@windriver.com>,
	openembedded-core@lists.openembedded.org
Cc: yue.tao@windriver.com
Subject: Re: [PATCH 0/3] Introduces kernel-initramfs recipe to resolve a implicit dependency issue
Date: Tue, 19 Jan 2016 22:37:36 +0100	[thread overview]
Message-ID: <569EACA0.8000007@gmail.com> (raw)
In-Reply-To: <569E8FDB.3000401@windriver.com>



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
>>
>



  reply	other threads:[~2016-01-19 21:37 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
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 [this message]
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=569EACA0.8000007@gmail.com \
    --to=liu.ming50@gmail.com \
    --cc=bruce.ashfield@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=yue.tao@windriver.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.