All of lore.kernel.org
 help / color / mirror / Atom feed
From: Erwan Velu <e.velu@criteo.com>
To: Michael Chang <mchang@suse.com>,
	The development of GNU GRUB <grub-devel@gnu.org>
Cc: dkiper@net-space.pl, daniel.kiper@oracle.com,
	alexander.burmashev@oracle.com, phcoder@gmail.com,
	Arthur Mesh <amesh@juniper.net>
Subject: Re: [PATCH v2] kern/efi: Adding efi-watchdog command
Date: Fri, 3 Sep 2021 08:33:49 +0200	[thread overview]
Message-ID: <430b82c2-cda3-07ad-4050-f6f5456027ef@criteo.com> (raw)
In-Reply-To: <20210903020920.GA10996@mazu>

Le 03/09/2021 à 04:09, Michael Chang a écrit :
[...]
> I'd suggest to move this efi-watchdog command registration to
> grub_register_core_commands() in grub-core/kern/corecmd.c as that helps
> us tracing or knowing available commands in grub's rescue mode.
>
> Also it would be great to see the explaination why this command needs to
> be in the core. To my understandng it could be that users may want to
> disarm the watchdog to not interrupt their work in rescue mode during a
> troubleshooting or debug session, but I am not fully clear about the
> purpose.

Hey Michael,

I'm waiting for other reviews and will add your points into a V3.


You are perfectly right on the aim.

To be efficient, the watchdog must be enabled at soon as possible and so

cannot be set into the configuration file as we are far too late and issues

could have already hit GRUB (aka unable to read the filesystem).

So, once the option is set, every-time GRUB will boots the watchdog is 
enabled.


And yes, if you need to perform a debug session, you need being in a 
position to disable it.

That's why we need this commands in the low-level command sets of grub.

I'm not very familiar with GRUB internals, so if the corecmd is a better 
place and other agree on that,

I'll make the move in V3.


Erwan,



  reply	other threads:[~2021-09-03  6:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-02 16:50 [PATCH v2] kern/efi: Adding efi-watchdog command Erwan Velu
2021-09-03  2:09 ` Michael Chang
2021-09-03  6:33   ` Erwan Velu [this message]
2021-09-07 11:20     ` Erwan Velu
2021-09-07 18:01       ` Daniel Kiper
2021-09-07 18:28         ` Erwan Velu
2021-09-09 15:46 ` Daniel Kiper
2021-09-10 10:34   ` Erwan Velu
2021-09-13 14:12     ` 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=430b82c2-cda3-07ad-4050-f6f5456027ef@criteo.com \
    --to=e.velu@criteo.com \
    --cc=alexander.burmashev@oracle.com \
    --cc=amesh@juniper.net \
    --cc=daniel.kiper@oracle.com \
    --cc=dkiper@net-space.pl \
    --cc=grub-devel@gnu.org \
    --cc=mchang@suse.com \
    --cc=phcoder@gmail.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.