From: Tom Rini <trini@konsulko.com>
To: Ed Bartosh <ed.bartosh@linux.intel.com>
Cc: Christopher Larson <chris_larson@mentor.com>,
openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] wic: Generate startup.nsh for EFI cases if none found
Date: Thu, 28 Sep 2017 13:44:29 -0400 [thread overview]
Message-ID: <20170928174429.GO3112@bill-the-cat> (raw)
In-Reply-To: <20170928154707.362zfbhccbydkdox@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1871 bytes --]
On Thu, Sep 28, 2017 at 06:47:07PM +0300, Ed Bartosh wrote:
> On Wed, Sep 20, 2017 at 12:03:27PM -0400, Tom Rini wrote:
> > In the case of non-wic images there is logic today to generate a
> > startup.nsh file that will be executed by EFI to run the loader that the
> > image contains. In the WIC case is currently depends on that file being
> > generated elsewhere and placed in DEPLOY_DIR_IMAGE and only used if
> > present there.
>
> What's wrong with this approach?
No one ever provides a startup.nsh and everyone that wants one creates
the same one line trivial example. The end result is that no WIC images
are Just Bootable on UEFI systems unless you first go and spell that out
as the desired booting device. This isn't an awesome workflow which is
why the non-WIC cases make the required startup.nsh :)
> I'd be happy to make wic to do only partitioning and assembling the
> image and avoiding to modify image content as much as possible.
> That would make wic design much more clear and let us to remove
> a lot of duplication between wic and meta/classes code.
>
> Regarding boot partition content, I think preparing it from bootfs
> directory the same way as it's done for root partition is the way to go.
> You can find more details about it here:
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10073
I don't conceptually see a problem with going that route. But today WIC
images aren't nearly as useful as they could be, with a rather tiny
change.
My patch is also a regression-fix, I believe, in that at some point in
the past, when Christopher's patch went in, things were laid out such
that startup.nsh was often/always generated by another class and placed
where WIC would find it and copy it in. At some point that was
broken/changed, and no one noticed / was interested enough to fix it.
--
Tom
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2017-09-28 17:44 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-20 16:03 [PATCH] wic: Generate startup.nsh for EFI cases if none found Tom Rini
2017-09-28 15:47 ` Ed Bartosh
2017-09-28 17:44 ` Tom Rini [this message]
2017-09-28 17:46 ` Otavio Salvador
2017-09-28 17:49 ` Tom Rini
2017-09-28 17:57 ` Otavio Salvador
2017-09-28 17:59 ` Tom Rini
2017-09-28 18:01 ` Otavio Salvador
2017-09-28 18:04 ` Tom Rini
2017-09-29 11:27 ` Ed Bartosh
2017-09-29 12:35 ` Tom Rini
2017-09-29 13:44 ` Ed Bartosh
2017-09-29 13:50 ` Tom Rini
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=20170928174429.GO3112@bill-the-cat \
--to=trini@konsulko.com \
--cc=chris_larson@mentor.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