make 'sleep --interruptible 0' interruptible

Hello,

Attached patch makes sleep -i 0 "interruptible". It allows to have 0 sleep yet selectable multiboot config i.e.

if sleep --interruptible 0 ; then
set timeout=0
fi

Szymon K. Janc
[email protected] // GG: 1383435

@@ -44,19 +44,26 @@
   grub_printf ("%d    ", n);
 }
 
+static int
+do_check_key_press (void)
+{
+  return (grub_checkkey () >= 0
+      && GRUB_TERM_ASCII_CHAR (grub_getkey ()) == GRUB_TERM_ESC);
+}
+
 /* Based on grub_millisleep() from kern/generic/millisleep.c.  */
 static int
 grub_interruptible_millisleep (grub_uint32_t ms)
 {
   grub_uint64_t start;
-
   start = grub_get_time_ms ();
-
+  
   while (grub_get_time_ms () - start < ms)
-    if (grub_checkkey () >= 0 &&
-	GRUB_TERM_ASCII_CHAR (grub_getkey ()) == GRUB_TERM_ESC)
+  {
+    if (do_check_key_press ())
       return 1;
-
+  }
+  
   return 0;
 }
 

@@ -64,18 +71,20 @@
 grub_cmd_sleep (grub_extcmd_t cmd, int argc, char **args)
 {
   struct grub_arg_list *state = cmd->state;
-  int n;
+  unsigned long n;
 
   if (argc != 1)
     return grub_error (GRUB_ERR_BAD_ARGUMENT, "missing operand");
 
   n = grub_strtoul (args[0], 0, 10);
 
+  if (n == ~0UL)
+    return grub_error (GRUB_ERR_BAD_ARGUMENT, "incorrect value");
+
   if (n == 0)
-    {
-      /* Either `0' or broken input.  */
-      return 0;
-    }
+  {
+     return (state[1].set && do_check_key_press ());
+  }
 
   pos = grub_term_save_pos ();
 

Hmm now I see that this trivial case is no so trivial at all. Yet it would be nice to have unified sollution for GRUB_HIDDEN_TIMEOUT.

Maybe extra command especially for user interactivity? It would combine functionality of sleep and keystatus without need to worry about restrictions mentioned in previous discussion.
I know that this is somewhat redundant but it looks like it would be very hard for 'clean' solution.

Szymon K. Janc
[email protected] // GG: 1383435

We're going to migrate to hardware drivers (at_keyboard / usb_keyboard) in the near future. I guess this resolves the stated problem, so I wouldn't invest a lot of effort in finding other solutions to it.

If you want to help with polishing at_keyboard, usb_keyboard and the USB stack, that'd be most welcome.

Robert Millan

  "Be the change you want to see in the world" -- Gandhi

If anything, at_keyboard currently makes the problem worse.

The reason we can tell instantaneously whether a modifier key is held down is that the BIOS remembers that state and exposes it in a magic memory location. For other keys, we just get make and break keycodes when those keys are pressed and released respectively. at_keyboard deals with modifiers by tracking make and break keycodes, but this does not cope with the case where a modifier key was held down when GRUB starts. In the case of a very short timeout, it is much more common for a modifier key to be already held down when GRUB starts (i.e. user presses the power button and then leans on Shift until something happens), rather than the user managing to press the modifier key in just the right window of time.

I think that, on BIOS systems, at_keyboard should "import" the state of modifier keys from the BIOS when it starts up, and then track make and break keycodes from then on. That would deal with the regression from the BIOS-based driver, at the cost of reintroducing a small dependency on the BIOS (but it would just be at startup time and would consist only of checking a memory location).

Either way, it's still not possible to check for non-modifier keys without having some kind of delay, since the BIOS hasn't tracked those keys from system startup for us, so the stated problem still stands. As far as I know, this problem is simply insoluble in GRUB on BIOS-based systems. (The problem isn't unique to BIOS either.)

Colin Watson                                       [[email protected]]