All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v2 1/1] boot/systemd-boot: new package
Date: Sat, 15 Dec 2018 12:00:35 +0100	[thread overview]
Message-ID: <20181215110035.GE2625@scaer> (raw)
In-Reply-To: <CADvTj4qfxJmefVR71juMxMdoV7+ua5Utt4cUGhPCnDXFUtBXDA@mail.gmail.com>

James, All,

On 2018-12-15 03:43 -0700, James Hilliard spake thusly:
> On Sat, Dec 15, 2018 at 3:27 AM Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> > On 2018-12-15 02:12 -0700, James Hilliard spake thusly:
[--SNIP--]
> > > I did it this way so that it's clear that systemd-boot can be built
> > > without a systemd init system.
> >
> > There, _that_ is the reason for all this complexity.
> >
> > So, let me suggest two alternative options that avoid all this mess:
> >
> >  1- make systemd-boot available only for systemd-based init,
> >
> >  2- just do a systemd-boot package (in boot/) that is a whole package on
> >     its own, and just happens to build just the systemd-boot part of
> >     systemd.
> >
> > I would very much favour the first option, because it is very simple, as
> > it just requires a *few* tweaks in the existing sytemd.mk, i.e.
> > basically:
> >
> >     ifeq ($()BR2_PACKAGES_SYSTEMD_BOOT,y)
> >     SYSTEMD_CONF_OPTS += \
> >         -Defi=true \
> >         -Dgnu-efi=true \
> >         -Dcc-efi=blabla \
> >         [...]
> >     else
> >     SYSTEMD_CONF_OPTS += -Defi=false -Dgnu-efi=false
> >     endif
> it would also need the SYSTEMD_INSTALL_IMAGES_CMDS part.

Yes, obviously my code snippet was there just as a seed for a proper,
complete change...

> > Also, I wonder if it ever makes sense to provide systemd-boot to
> > non-systemd init systems to begin with.
> I think it does,

Yes, Peter provided a good use-case, indeed.

> systemd-boot is even designed to boot operating
> systems without systemd, including windows.

Aha, you almost got me there, I almost thought you were serious (in the
Buildroot context, I mean). ;-)

> > Baring that, option 2 is pretty simple as well. It's a separate package
> > that just happens to share its source code with another one, like we
> > have with mesa3d and mesa3d-headers (just as an example).
> I tried that approach first in my v1 patch, I abandoned it since

Yet, I think we should really go that route.

> systemd-boot needed to be built at the same time as the userspace
> tools for systems that have a systemd init system for the integration
> to work properly.

OK, so we need to think it a bit, then. Is it the boot part that needs
the userland part, of the userland that needs the boot part, of they
both need to know each other?

One option I can think of quickly, is that we could have a systemd-boot
package that is only available when systemd is not enabled, and an option
in systemd to install the boot part when systemd is enabled.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

  reply	other threads:[~2018-12-15 11:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-14 11:42 [Buildroot] [PATCH v2 1/1] boot/systemd-boot: new package james.hilliard1 at gmail.com
2018-12-15  8:58 ` Yann E. MORIN
2018-12-15  9:12   ` James Hilliard
2018-12-15 10:27     ` Yann E. MORIN
2018-12-15 10:43       ` Peter Korsgaard
2018-12-15 10:47         ` James Hilliard
2018-12-15 10:49         ` Yann E. MORIN
2018-12-15 10:43       ` James Hilliard
2018-12-15 11:00         ` Yann E. MORIN [this message]
2018-12-15 11:09           ` James Hilliard
2018-12-15 13:47             ` Yann E. MORIN

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=20181215110035.GE2625@scaer \
    --to=yann.morin.1998@free.fr \
    --cc=buildroot@busybox.net \
    /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.