From owner-svn-src-all@FreeBSD.ORG Sun Dec 18 07:35:28 2011 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D47F3106564A; Sun, 18 Dec 2011 07:35:28 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id 6C83A8FC0C; Sun, 18 Dec 2011 07:35:28 +0000 (UTC) Received: from c211-28-227-231.carlnfd1.nsw.optusnet.com.au (c211-28-227-231.carlnfd1.nsw.optusnet.com.au [211.28.227.231]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id pBI7ZOZB007432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Dec 2011 18:35:25 +1100 Date: Sun, 18 Dec 2011 18:35:24 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Andriy Gapon In-Reply-To: <201112171508.pBHF8ibC064202@svn.freebsd.org> Message-ID: <20111218173749.N1196@besplex.bde.org> References: <201112171508.pBHF8ibC064202@svn.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 07:35:28 -0000 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