Re: Inconsistent behaviour of "keystatus" in a waiting loop

[Andrei Borzenkov]

В Tue, 19 May 2015 16:14:09 +0200
"Arbiel (gmx)" <address@hidden> пишет:

> 
> 
> Le 19/05/2015 05:39, Andrei Borzenkov a écrit :
> 
> Let me explain what I want to do.
> Running a GNU/Linux system, I want  the user to set a grub environment
> variable into
> the grubenv environment block to instruct grub to perform a specific
> task at next boot,
> but only once, at that specific next boot.
> When grub performs that specific task, it resets the environment
> variable with a "save_env" statement.
> Unfortunetaly, grub cannot write into a LVM partition neither in some
> specific file systems
> (btrfs, cpiofs, newc, odc, romfs, …).
> So, if the save_env statement returns an error condition, I want grub to
> 1)instruct the user either to press "Ctrl" key to perform the task or
> "Alt" to forget about it and boot normally and
> 2) wait until the user has got time to read and understand the
> instructions and pressed the desired key.
> 
> > Ð’ Mon, 18 May 2015 22:24:00 +0200
> > "Arbiel (gmx)" <address@hidden> пишет:
> >
> >> Hi
> >>
> >> I wish to have grub wait until the user has taken a specific action and
> >> presses down a key, such as control, shift or alt keys to inform the
> >> action has been taken. It's possible to test this with the keystatus
> >> --<key> function.
> >>
> >> With the following lines
> >>
> >>     echo "Press Ctrl key down to go on." ;
> >>     until keystatus --ctrl ; do true ; done ;
> >>     echo "Ctrl key pressed down." ;
> >>
> >> grub seems to enter and endless loop. However, if the Ctrl key is
> >> pressed before the "Press Ctrl key down to go on." message is displayed,
> >> grub immediately exits the loop.
> >>
> > keystatus checks whether key state is "pressed". It has no way to know
> > since when key is pressed. It does not check for transition, it checks
> > for state. What behavior you expect when key is pressed before loop
> > starts?
> I do not expect anything else than what you explain : keystatus checking
> the state
> of the key in real time and returning it into a boolean value, true if
> the key is down at the time of
> the statement being executed, false if it is up.
> It turns out that, if I press the key after the first message and so
> after the first keystatus statement,
> grub seems to loop endlessly, as if never finding the key to be down,
> even if it really is down.

Ah, sorry, I misunderstood. Yes, I see this behavior. The problem is,
on PC BIOS getkeystatus simply checks flags in BIOS Data Area and in
your first loop BIOS never gets chance to run and update these flags.
While in your second loop sleep actually polls for input characters and
so allows BIOS to set flags.

I see two possible solutions.

Brute force and easy one - add --milliseconds switch to sleep command
to minimize delay. Internally sleep is using milliseconds anyway. Care
to send patch to grub-devel?

Long term getkeystatus on PC BIOS should probably actually poll
keyboard. Unfortunately it is less trivial. Do you have experience with
low level PC programming?

...
> If the plateform is not able to check the status of the keys, what do
> you suggest me
> to do ?
> 
> 

It probably depends on how often you are expecting to see such
configuration. It does not really depend on platform - serial console
on any system has no way to do it, so you can in principle see it
anywhere.

It is not really specific to GRUB in any way. How would you implement
it when logged into remote system over telnet/ssh?

pgpFAg1vfdkxH.pgp
Description: OpenPGP digital signature