Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 18 Dec 2011 18:35:24 +1100 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        Andriy Gapon <avg@freebsd.org>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r228631 - in head/sys: dev/cfe dev/dcons dev/ofw dev/sio dev/syscons dev/uart dev/usb/serial dev/xen/console gdb ia64/ia64 kern mips/adm5120 pc98/cbus powerpc/mambo sys
Message-ID:  <20111218173749.N1196@besplex.bde.org>
In-Reply-To: <201112171508.pBHF8ibC064202@svn.freebsd.org>
References:  <201112171508.pBHF8ibC064202@svn.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 17 Dec 2011, Andriy Gapon wrote:

> Log:
>  kern cons: introduce infrastructure for console grabbing by kernel
>
>  At the moment grab and ungrab methods of all console drivers are no-ops.
>
>  Current intended meaning of the calls is that the kernel takes control of
>  console input.  In the future the semantics may be extended to mean that
>  the calling thread takes full ownership of the console (e.g. console
>  output from other threads could be suspended).
>
>  Inspired by:	bde
>  MFC after:	2 months

Thanks.  I didn't keep up with the details.

> Modified: head/sys/dev/cfe/cfe_console.c
> ==============================================================================
> --- head/sys/dev/cfe/cfe_console.c	Sat Dec 17 14:55:19 2011	(r228630)
> +++ head/sys/dev/cfe/cfe_console.c	Sat Dec 17 15:08:43 2011	(r228631)
> @@ -76,6 +76,8 @@ static cn_init_t	cfe_cninit;
> static cn_term_t	cfe_cnterm;
> static cn_getc_t	cfe_cngetc;
> static cn_putc_t	cfe_cnputc;
> +static cn_grab_t	cfe_cngrab;
> +static cn_ungrab_t	cfe_cnungrab;
>
> CONSOLE_DRIVER(cfe);
>
> @@ -183,6 +185,18 @@ cfe_cnterm(struct consdev *cp)
>
> }
>
> +static void
> +cfe_cngrab(struct consdev *cp)
> +{
> +
> +}
> +
> +static void
> +cfe_cnungrab(struct consdev *cp)
> +{
> +
> +}
> +
> static int
> cfe_cngetc(struct consdev *cp)
> {

I prefer NULL function pointers to dummy functions.  The horrible
CONSOLE_DRIVER() macro gets in the way of this.  FreeBSD[3-4] and maybe
FreeBSD-2 use the slightly less horrible CONS_DRIVER() macro.  FreeBSD-1
uses a normal unobfuscated struct initializer but with an even more
horrible implementation (the entry points had to exist and be public
functions, so that the initializer could be hard-coded in another file
depending on ifdefs for driver existence, and this file was not even
generated by config.  cdevsw initialization was similarly horrible in
FreeBSD-1).

> ...
> Modified: head/sys/sys/cons.h
> ==============================================================================
> --- head/sys/sys/cons.h	Sat Dec 17 14:55:19 2011	(r228630)
> +++ head/sys/sys/cons.h	Sat Dec 17 15:08:43 2011	(r228631)
> @@ -58,6 +60,10 @@ struct consdev_ops {
> 				/* kernel getchar interface */
> 	cn_putc_t	*cn_putc;
> 				/* kernel putchar interface */
> +	cn_grab_t	*cn_grab;
> +				/* grab console for exclusive kernel use */
> +	cn_ungrab_t	*cn_ungrab;
> +				/* ungrab console */
> };
>
> struct consdev {
> @@ -99,6 +105,8 @@ extern	struct tty *constty;	/* Temporary
> 		.cn_term = name##_cnterm,				\
> 		.cn_getc = name##_cngetc,				\
> 		.cn_putc = name##_cnputc,				\
> +		.cn_grab = name##_cngrab,				\
> +		.cn_ungrab = name##_cnungrab,				\
> 	};								\
> 	CONSOLE_DEVICE(name##_consdev, name##_consdev_ops, NULL)
>

With C99 initializers, which are already used here, the macros become
just obfuscations.  The CONSOLE_DEVICE() macro handles the minor problem
that without it the driver would have to know the order of the parameters
in a macro like the old CONS_DRIVER() one (to invoke such a macro), or
the order of struct members including ones not supported by the driver
(to declare an initializer).  This was only a minor problem, and the
macros were silly, since there were approximately a whole 2 console
drivers but there were hundreds of generic drivers and dozens of file
systems that face the problem without any macros to obfuscate it, and
just declared the initializers for the much larger cdevsw and vfsops
structs.  CONSOLE_DRIVER() has the costs of requiring actual functions
with a specific spelling for all entry points.

Now C99 initializers under full control of the driver or file system
are used for cdevsw and vfsops structs, but the silly macros are still
used for console drivers.

BTW, there is probably lots of disorder in the C99 initializers.  I
think most cdevsw initializers are in bad historical order.  ufs_vfsops
was converted to alphabetical ordering on the struct member name when
it was converted to a C99 initializer, but has accreted insertion sort
errors for .vfs_cmount in the middle and .vfs_susp_clean at the end.
It also has a namespace error for the .vfs_susp_clean entry (the
public function for this is not in the ffs_ namespace).

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111218173749.N1196>