From: "Jan Hendrik Farr" <kernel@jfarr.cc>
To: "Jarkko Sakkinen" <jarkko@kernel.org>, linux-kernel@vger.kernel.org
Cc: kexec@lists.infradead.org, x86@kernel.org, tglx@linutronix.de,
dhowells@redhat.com, vgoyal@redhat.com, keyrings@vger.kernel.org,
akpm@linux-foundation.org, "Baoquan He" <bhe@redhat.com>,
bhelgaas@google.com, lennart@poettering.net,
"Luca Boccassi" <bluca@debian.org>
Subject: Re: [PATCH 0/1] x86/kexec: UKI support
Date: Tue, 12 Sep 2023 21:38:59 +0200 [thread overview]
Message-ID: <3cb7629f-9dd9-430a-86a0-5acb32882018@app.fastmail.com> (raw)
In-Reply-To: <CVH6NGLENMPH.271W6X80061M@suppilovahvero>
> These are sort of "tautological" arguments. There must be some
> objective reasons why this architecture was chosen instead of
> other (i.e. using what already pre-exists).
You mean like your argument that the same can already be achieved with the normal EFI stub and builin initrd/cmdline? ;)
I think only reasons #4 and the last paragraph in me response relate to it being pre-existing. The other reasons are actual limitations with the normal EFI stub setup. Doesn't mean that they can't be overcome, but UKIs work.
I'm not sure what the initial reasons where for coming up with this architecture were, I was not involved.
What I can tell you is that right now it is a format that has practical advantages and that there are generic mainstream distros looking to adopt it. So having the capability to kexec them is gonna come in handy.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2023-09-12 19:39 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-09 16:18 [PATCH 0/1] x86/kexec: UKI support Jan Hendrik Farr
2023-09-09 16:18 ` [PATCH 1/1] " Jan Hendrik Farr
2023-09-09 17:15 ` [PATCH 0/1] " Luca Boccassi
2023-09-09 17:57 ` Jan Hendrik Farr
2023-09-09 18:10 ` Luca Boccassi
2023-09-11 3:23 ` Jan Hendrik Farr
2023-09-11 22:02 ` Jarkko Sakkinen
2023-09-11 22:54 ` Jan Hendrik Farr
2023-09-12 10:33 ` Jarkko Sakkinen
2023-09-12 15:32 ` Jan Hendrik Farr
2023-09-12 17:41 ` Jarkko Sakkinen
2023-09-12 18:56 ` Jan Hendrik Farr
2023-09-12 19:24 ` Jarkko Sakkinen
2023-09-12 19:38 ` Jan Hendrik Farr [this message]
2023-09-12 20:49 ` Jan Hendrik Farr
2023-09-13 14:45 ` Jarkko Sakkinen
2023-09-13 15:07 ` Jan Hendrik Farr
2023-09-13 15:58 ` Jarkko Sakkinen
2023-09-14 9:11 ` Lennart Poettering
2023-09-14 12:12 ` Jarkko Sakkinen
2023-09-14 8:48 ` Lennart Poettering
2023-09-14 11:52 ` Jarkko Sakkinen
2023-09-11 23:20 ` [systemd-devel] " Neal Gompa
2023-09-12 10:37 ` Jarkko Sakkinen
2023-09-18 15:41 ` Dimitri John Ledkov
2023-09-25 16:43 ` Jarkko Sakkinen
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=3cb7629f-9dd9-430a-86a0-5acb32882018@app.fastmail.com \
--to=kernel@jfarr.cc \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=bhelgaas@google.com \
--cc=bluca@debian.org \
--cc=dhowells@redhat.com \
--cc=jarkko@kernel.org \
--cc=kexec@lists.infradead.org \
--cc=keyrings@vger.kernel.org \
--cc=lennart@poettering.net \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=vgoyal@redhat.com \
--cc=x86@kernel.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