Date: Mon, 29 Aug 2011 16:06:26 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Bruce Evans <brde@optusnet.com.au> Cc: "svn-src-head@FreeBSD.org" <svn-src-head@FreeBSD.org>, "svn-src-all@FreeBSD.org" <svn-src-all@FreeBSD.org>, "src-committers@FreeBSD.org" <src-committers@FreeBSD.org>, Hans Petter Selasky <hselasky@c2i.net> Subject: Re: svn commit: r223989 - head/sys/dev/usb/input Message-ID: <4E5B8ED2.8030109@FreeBSD.org> In-Reply-To: <20110720221325.E1436@besplex.bde.org> References: <201107181610.49443.hselasky@c2i.net> <4E26AFF8.8080107@FreeBSD.org> <201107201249.39550.hselasky@c2i.net> <20110720221325.E1436@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E5B8ED2.8030109>