grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] hidemenu fix


From: Robert Millan
Subject: Re: [PATCH] hidemenu fix
Date: Sat, 11 Jul 2009 20:53:10 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

On Sat, Jul 11, 2009 at 01:26:50PM +0800, Bean wrote:
> Hi,
> 
> This patch moves the screen init code from reader to menu, so that
> hidemenu would work as before. A minor side effect is that if grub.cfg
> is not found, the "GNU GRUB" header would not be printed, but I guess
> this is not an issue.

Hi Bean,

I don't understand this very well.  First of all, which part is supposed
to be responsible for printing the header?  Are you changing that?  Right
now it is being printed twice.

> -static grub_err_t
> -grub_rescue_init (void)
> -{
> -  grub_printf ("Entering rescue mode...\n");
> -  return 0;
> -}
> -
>  /* Prompt to input a command and read the line.  */
>  static grub_err_t
>  grub_rescue_read_line (char **line, int cont)
> @@ -77,7 +70,6 @@ grub_rescue_read_line (char **line, int cont)
>  static struct grub_reader grub_rescue_reader =
>    {
>      .name = "rescue",
> -    .init = grub_rescue_init,
>      .read_line = grub_rescue_read_line
>    };

Why is grub_rescue_init being removed?

> @@ -524,7 +517,6 @@ grub_normal_read_line (char **line, int cont)
>  static struct grub_reader grub_normal_reader =
>    {
>      .name = "normal",
> -    .init = grub_normal_reader_init,
>      .read_line = grub_normal_read_line
>    };

And this one, too.  If readers are no longer responsible for printing a
header, shouldn't we adjust whatever code that was calling their
init functions, and the grub_reader struct as well?

This patch looks like a kludge to me.  Can we discuss what's wrong with the
current design, and what options do we have to solve this?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."




reply via email to

[Prev in Thread] Current Thread [Next in Thread]