svn commit: r223989 - head/sys/dev/usb/input
Andriy Gapon
avg at FreeBSD.org
Mon Aug 29 13:11:45 UTC 2011
Having got my feet a little bit wet in this code I have only the following to add:
on 20/07/2011 18:32 Bruce Evans said the following:
[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.
I completely agree.
> BTW, gets(9) is bogusly named. It is not harmful like gets(3),
> since it takes a buffer size arg. It is used approximately once,
> for mountroot input, so renaming it would be easy. Perhaps it
> should be named cn_gets() and be implemented closer to the console
> driver, or be implemented closer to printf() (it is now in libkern).
Again, I completely agree.
Perhaps there should also be a variant that works in an interrupt driven mode, if
possible, exactly for the mountroot prompt and similar.
> For debugger entry and panics, the whole operation should be wrapped
> by cn_open()/cn_close(). This covers most cases. Some console drivers
> now sort of work in debugger mode by abusing the kdb_active variable,
> or because debugger entry stops interrupts and other CPUs.
Yes and yes.
[snip]
> There should be significant differences, but were only small ones
> in practice, between being in debugger mode and being in polling
> mode. For example, entering console i/o mode for syscons should
> involve switching the video mode and perhaps the frame buffer to
> a special one, in case the current one is unusable for some reason
> (it might be controlled by X, or in the middle of an initialization,
> or you might just want to avoid scribbling on its frame buffer).
> Thus, entering console i/o mode might be an extemely heavyweight
> operation. You don't want to do it on every entry to debugger mode.
> Even if the switch is very fast, it would make the screen flicker
> to switch the frame buffer on every entry to the debugger for things
> like tracing (but not displaying) every instruction when single
> stepping using 'n' in ddb.
This is a little bit different from the main topic, but I agree that entering kdb
should ensure that the video console is fully usable if it's configured.
[snip]
So, all in all, just voicing my agreement in a hope that these ideas do not get
forgotten again.
P.S. I would like to forward this email to arch@ if nobody objects.
--
Andriy Gapon
More information about the svn-src-head
mailing list