On Thu, Sep 28, 2017 at 02:57:04PM -0300, Otavio Salvador wrote:
> On Thu, Sep 28, 2017 at 2:49 PM, Tom Rini <tr...@konsulko.com> wrote:
> > On Thu, Sep 28, 2017 at 02:46:23PM -0300, Otavio Salvador wrote:
> >> Hello Tom,
> >>
> >> On Thu, Sep 28, 2017 at 2:44 PM, Tom Rini <tr...@konsulko.com> wrote:
> >> > 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 think it could be done as we did for u-boot-extlinux support.
> >
> > That's complete overkill for a static one line file.
> 
> No, it is not. It allows for reproducable builds.

Either solution would allow for reproducible builds.  Perhaps it would
be clearer if the patch just always generated that content instead like
the systemd and grub2 classes do?

-- 
Tom

Attachment: signature.asc
Description: Digital signature

-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Reply via email to