some syscons ideas
Andriy Gapon
avg at FreeBSD.org
Wed Aug 31 09:34:12 UTC 2011
I thought that it would be useful to forward this email here too.
The original Bruce's email can be found by its message id or via this link:
http://article.gmane.org/gmane.os.freebsd.devel.cvs/437692
-------- Original Message --------
Message-ID: <4E5B8ED2.8030109 at FreeBSD.org>
Date: Mon, 29 Aug 2011 16:06:26 +0300
From: Andriy Gapon <avg at FreeBSD.org>
To: Bruce Evans <brde at optusnet.com.au>
Subject: Re: svn commit: r223989 - head/sys/dev/usb/input
References: <201107181610.49443.hselasky at c2i.net> <4E26AFF8.8080107 at FreeBSD.org>
<201107201249.39550.hselasky at c2i.net> <20110720221325.E1436 at besplex.bde.org>
In-Reply-To: <20110720221325.E1436 at besplex.bde.org>
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 freebsd-arch
mailing list