From: Robbie Harwood <rharwood@redhat.com>
To: Daniel Kiper <dkiper@net-space.pl>
Cc: grub-devel@gnu.org, Raymund Will <rw@suse.com>,
John Jolly <jjolly@suse.com>,
Javier Martinez Canillas <javierm@redhat.com>
Subject: Re: [PATCH v2 1/1] Add support for grub-emu to kexec Linux menu entries
Date: Mon, 08 Aug 2022 14:58:06 -0400 [thread overview]
Message-ID: <jlgiln2lg01.fsf@redhat.com> (raw)
In-Reply-To: <20220803152639.cne3dtxofhqakjqr@tomti.i.net-space.pl>
[-- Attachment #1: Type: text/plain, Size: 1730 bytes --]
Daniel Kiper <dkiper@net-space.pl> writes:
> On Tue, Jul 19, 2022 at 04:39:34PM -0400, Robbie Harwood wrote:
>
>> +static grub_err_t
>> +grub_linux_boot (void)
>> +{
>> + grub_err_t rc = GRUB_ERR_NONE;
>> + char *initrd_param;
>> + const char *kexec[] = { "kexec", "-l", kernel_path, boot_cmdline, NULL, NULL };
>> + const char *systemctl[] = { "systemctl", "kexec", NULL };
>
> I would prefer if we do not hardcode these commands. E.g. kexec
> command has many options which can be useful for debugging. If we
> hardcode the command here we cannot use these options.
Can you clarify what you would like to see instead? I'm not sure what
the alternative would be.
>> + rc = grub_util_exec (systemctl);
>> +
>> + if (rc == GRUB_ERR_NONE)
>> + return rc;
>> +
>> + grub_error (rc, N_("Error trying to perform 'systemctl kexec'"));
>> +
>> + /* need to check read-only root before resetting hard!? */
>> + grub_dprintf ("linux", "Performing 'kexec -e -x'");
>
> I would really do not fall back to 'kexec -e' by default. It is too
> dangerous. And again I would not hardcode this command too.
Same question as above regarding the alternative... also, can you
elaborate on the danger you see here?
>> + grub_fatal (N_("Use '"PACKAGE"-emu --kexec' to force a system restart."));
>> +
>> + grub_dprintf ("linux", "Performing 'systemctl kexec' (%s) ",
>> + (kexecute==1) ? "do-or-die" : "just-in-case");
>
> s/kexecute==1/kexecute/
>
> Please be more consistent how you check kexecute.
None of this is my code yet - I just rebased the existing patch - but
I will make these and other requested changes :) Thanks for the review;
I'll cut another version once we resolve the conversations above.
Be well,
--Robbie
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]
next prev parent reply other threads:[~2022-08-08 18:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-19 20:39 [PATCH v2 1/1] Add support for grub-emu to kexec Linux menu entries Robbie Harwood
2022-08-03 15:26 ` Daniel Kiper
2022-08-08 18:58 ` Robbie Harwood [this message]
2022-08-11 18:08 ` Daniel Kiper
2022-08-15 13:16 ` Raymund Will
2022-08-16 16:07 ` Robbie Harwood
2022-08-20 11:23 ` Daniel Kiper
2022-08-23 21:03 ` Robbie Harwood
2022-08-08 21:43 ` Vladimir 'phcoder' Serbinenko
2022-08-11 18:02 ` Robbie Harwood
2022-08-11 18:13 ` Daniel Kiper
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=jlgiln2lg01.fsf@redhat.com \
--to=rharwood@redhat.com \
--cc=dkiper@net-space.pl \
--cc=grub-devel@gnu.org \
--cc=javierm@redhat.com \
--cc=jjolly@suse.com \
--cc=rw@suse.com \
/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.