Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Adrian Freihofer <adrian.freihofer@gmail.com>
To: ed.bartosh@linux.intel.com
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [wic][PATCH] wic: Implement --build-rootfs command line option
Date: Mon, 20 Apr 2015 18:13:20 +0200	[thread overview]
Message-ID: <1429546400.1918.13.camel@gmail.com> (raw)

Let wic call bitbake seems to be a great idea.

One question is open to me. What's the recommended approach to resolve
the dependencies between the image, the bootloader and native tools
which are additionally required to create the final disk image?
Basically the right place to resolve this dependency is the kickstart
file. Bitbake should not even know that syslinux or any other bootloader
will be added to the final disk image. In other words
IMAGE_EXTRA_DEPENDS or similar are not the right place to add the
bootloader dependency anymore. But if bitbake does not provide e.g.
syslinux-native wic will fail to use it. This is kind of a chicken egg
problem...
A nice solution would be if wic would maintain a simple dependency list
For example: There is a kickstart file assembling a disk image including
my-mini-image and syslinux-native. To create the partition layout,
parted-native is required as well. Hence bitbake should be called like
this: "bitbake my-mini-image parted-native syslinux-native" before wic
starts assembling the disk image. my-mini-image is provided by the -e
parameter of wic. The latter two tools should be provided by the wic
plugins creating the partitions and the disk image. My proposal is to
extend the internal API of wic by a dependency list where plugins can
append required tools e.g. during start up of wic. This would enable the
disk plugin to request "parted-native" and the boot partition plugin to
request "syslinux-native" before bitbake is called.
Further on one more problem could be solved easily. If wic takes care
about the final disk assembly bitbake --fetch-only might not be
sufficient to download everything needed to create the whole firmware.
This makes it hard to create a complete premirror. If wic would support
the dependency list as mentioned above and provide a command line
parameter --fetch-only everything would be consistent. Instead of
calling "bitbake  my-mini-image  --fetch-only" the user just calls the
corresponding wic command with --fetch-only appended. This would result
in "bitbake my-mini-image parted-native syslinux-native --fetch-only".



             reply	other threads:[~2015-04-20 16:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-20 16:13 Adrian Freihofer [this message]
2015-04-21 12:39 ` [wic][PATCH] wic: Implement --build-rootfs command line option Ed Bartosh
  -- strict thread matches above, loose matches on Subject: below --
2015-04-07  9:57 Ed Bartosh
2015-04-08 22:18 ` João Henrique Ferreira de Freitas
2015-04-09 19:12   ` Ed Bartosh
2015-04-09 22:24     ` João Henrique Ferreira de Freitas
2015-04-10  9:16       ` Ed Bartosh

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=1429546400.1918.13.camel@gmail.com \
    --to=adrian.freihofer@gmail.com \
    --cc=ed.bartosh@linux.intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    /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