On Mon, 24 Aug 2009, Ed Schouten wrote:
> Allow multiple console devices per driver without insane code duplication.
> Say, a driver wants to have multiple console devices to pick from, you
> would normally write down something like this:
> Unfortunately, this means that you have to declare 10 cn routines,
> instead of 5. It also isn't possible to initialize cn_arg on beforehand.
> I noticed this restriction when I was implementing some of the console
> bits for my vt(4) driver in my newcons branch. I have a single set of cn
> routines (termcn_*) which are shared by all vt(4) console devices.
> In order to solve this, I'm adding a separate consdev_ops structure,
> which contains all the function pointers. This structure is referenced
> through consdev's cn_ops field.
> While there, I'm removing CONS_DRIVER() and cn_checkc, which have been
> deprecated for years. They weren't used throughout the source, until the
> Xen console driver showed up. CONSOLE_DRIVER() has been changed to do
> the right thing. It now declares both the consdev and consdev_ops
> structure and ties them together. In other words: this change doesn't
> change the KPI for drivers that used the regular way of declaring
> console devices.
CONS_DRIVER() was a good interface, unlike CONSOLE_DRIVER(). Removing it
completes the bitrot in the support for cn_dbctl, and completes removal
of cn_checkc's good name at the driver level.
cn_dbctl is still needed to unbreak sysctl's support for ddb (see db_main.c
22.214.171.124, which depends on cn_dbctl's infrastructure not having rotted) and
can be used to unbreak polled i/o in all console drivers (not just in ddb
mode -- it should have been named cn_ioctl) (see other mail).
The higher level cngetc() and cncheckc() are still correctly named, now
fully inconsistently with the driver level.