svn commit: r223989 - head/sys/dev/usb/input

[Andriy Gapon]

on 20/07/2011 18:32 Bruce Evans said the following:
[snip]
> The low-level console driver should switch to polling mode to read the
> keystrokes.  However, its API is broken as designed, so it can only
> [tell the driver level to] do this around each poll for a character.
> Polling involves polling each possible console in turn, so polling mode
> must be left after unsuccessfully polling for a short time so as to
> get to the next console.  This is now done even if there is only 1
> console.  Before the multiple-console changes, polling mode was only
> left after _successfully_ polling for as long as necessary to read
> a character, so things mostly worked -- the race was only lost if
> a character arrives in between polls, and you can't type fast enough
> for the time between polls to be significant compared with the time
> in polls.

[snip]

> A non-broken API needs cn_open() and cn_close() functions which would
> normally switch the driver in an out of polling mode.  Given these
> interfaces easy to fix the per-character poll to work as well as before
> the multiple console changes, including for multiple active consoles.
> Just call cn_open() and cn_close() on every active console around the
> whole polling loop.  A little more is required to prevent races between
> characters, and to avoid the races inherent in the cn_checkc() API.
> For multi-char input like that at the mountroot prompt, calling
> cn_open() and cn_close() around the loop in gets(9) is adequate.  The
> functions should be almost no-ops when called nested for things like
> this.

[snip]

Thank you for the great explanation of the issue!
I think that your suggestion makes a lot of sense and is the proper approach to
fixing this issue.  Now we need some sole to actually do the work :-)

-- 
Andriy Gapon