xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Roman Shaposhnik <roman@zededa.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "Jan Beulich" <jbeulich@suse.com>,
	Xen-devel <xen-devel@lists.xenproject.org>,
	grub-devel@gnu.org, "Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: multiboot2 and module2 boot issues via GRUB2
Date: Tue, 6 Apr 2021 11:03:12 -0700	[thread overview]
Message-ID: <CAMmSBy9w3VZpKdkSkpCAgDsRk0K24_Ssx-YvF9d_mpA8WetUkg@mail.gmail.com> (raw)
In-Reply-To: <f835e433-368c-b107-9963-9107d3432ce6@citrix.com>

[-- Attachment #1: Type: text/plain, Size: 2541 bytes --]

On Tue, Apr 6, 2021 at 10:51 AM Andrew Cooper <andrew.cooper3@citrix.com>
wrote:

> On 06/04/2021 09:19, Jan Beulich wrote:
> > On 01.04.2021 21:43, Andrew Cooper wrote:
> >> On 01/04/2021 09:44, Roger Pau Monné wrote:
> >>> On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote:
> >>>> On 01.04.2021 03:06, Roman Shaposhnik wrote:
> >>>>> And the obvious next question: is my EVE usecase esoteric enough that
> >>>>> I should just go ahead and do a custom GRUB patch or is there a more
> >>>>> general interest in this?
> >>>> Not sure if it ought to be a grub patch - the issue could as well
> >>>> be dealt with in Xen, by concatenating modules to form a monolithic
> >>>> initrd.
> >>> I would rather have it done in the loader than Xen, mostly because
> >>> it's a Linux boot specific format, and hence I don't think Xen should
> >>> have any knowledge about it.
> >>>
> >>> If it turns out to be impossible to implement on the loader side we
> >>> should consider doing it in Xen, but that's not my first option.
> >> Concatenating random things which may or may not be initrds is
> >> absolutely not something Xen should do.  We don't have enough context to
> >> do it safely/sensibly.
> > Well, I wasn't suggesting anywhere to concatenate random things.
> > Instead I was envisioning a command line option giving us the
> > context we need (e.g. "initrd=3+5").
>
> That's a massive layering violation, and incredibly fragile to the order
> of lines in the boot stanza.
>

Don't have enough karma to argue Xen architectural side of things, but...


> Either fix it by using a single monolithic initrd, which has worked
> perfectly well for the past 2 decades
>

...just to point out the obvious here:  even Debian who can HARDLY be
blamed for tracking the bleeding edge has been recommending this
for quite some time:

https://wiki.debian.org/DebianInstaller/NetbootFirmware#The_Solution:_Add_Firmware_to_Initramfs
Obviously there's no way to do that with Xen today out of the box.

Now, you can turn around and say "well, how hard could it be to
concatenate?". That's fair. But it is also fair to point out that everytime
we do that we portray Xen as "not quite as user friendly as X" (and
this is, of course, pure perception -- but if we want users to stick
perception matters a lot).

Thanks,
Roman.

P.S. Curiously enough, saying that -- I'm undermining my own case -- it is
actually
*easier* for me to hack GRUB in EVE. But I felt like stating the obvious
anyway.

[-- Attachment #2: Type: text/html, Size: 3585 bytes --]

  reply	other threads:[~2021-04-06 18:03 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-30 18:28 multiboot2 and module2 boot issues via GRUB2 Roman Shaposhnik
2021-03-30 19:08 ` Andrew Cooper
2021-04-01  1:06   ` Roman Shaposhnik
2021-04-01  7:31     ` Jan Beulich
2021-04-01  8:44       ` Roger Pau Monné
2021-04-01 19:43         ` Andrew Cooper
2021-04-06  8:19           ` Jan Beulich
2021-04-06 17:37             ` Roman Shaposhnik
2021-04-06 17:51             ` Andrew Cooper
2021-04-06 18:03               ` Roman Shaposhnik [this message]
2021-04-06 18:41                 ` Andrew Cooper
2021-04-07 20:50           ` Glenn Washburn
2021-04-08 16:48           ` Daniel Kiper
2021-03-30 19:35 ` Elliott Mitchell

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=CAMmSBy9w3VZpKdkSkpCAgDsRk0K24_Ssx-YvF9d_mpA8WetUkg@mail.gmail.com \
    --to=roman@zededa.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=grub-devel@gnu.org \
    --cc=jbeulich@suse.com \
    --cc=roger.pau@citrix.com \
    --cc=xen-devel@lists.xenproject.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;
as well as URLs for NNTP newsgroup(s).