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

[Arbiel (gmx)]

Le 19/05/2015 18:47, Andrei Borzenkov a écrit :
> Ð’ 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?
This solution will do it. However I don't know how to add the
milliseconds switch to the sleep command. The only information I found
concerning this command
http://members.iinet.net/~herman546/p20/GRUB2%20CLI%20Mode%20Commands.html#cli_sleep
only mentions waiting time in seconds.
>
> 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?
I have no experience in 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?
The option I am currently implementing is supposed to run locally only.
As for serial console, I will document the incompatibility.

Thank's you for the help.
>

signature.asc
Description: OpenPGP digital signature