Xen devel - Sep 2006 - [PATCH] Paravirt framebuffer use xvc as console [4/5]

This is the patch from Amos Waterland for the xenconsole to
use /dev/xvc0 instead of taking over ttys.  I''ve fixed a few places
which needed to check for XVC mode in addition to serial mode.  Also,
until LANANA responds with an official minor, I''ve adjusted it to use
char 250/187 (in the experimental range) as opposed to 204/187.

(Should be identical to this patch from last time)

Signed-off-by: Jeremy Katz <katzj@redhat.com>
Cc: Amos Waterland <apw@us.ibm.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> This is the patch from Amos Waterland for the xenconsole to
> use /dev/xvc0 instead of taking over ttys.  I''ve fixed a few
places
> which needed to check for XVC mode in addition to serial mode.  Also,
> until LANANA responds with an official minor, I''ve adjusted it to
use
> char 250/187 (in the experimental range) as opposed to 204/187.
> 
> (Should be identical to this patch from last time)
Does this have anything to do with the virtual framebuffer work, or
does it stand alone?
> diff -r 2b360c6b44fa -r c859588adc5e
linux-2.6-xen-sparse/drivers/xen/console/console.c
> --- a/linux-2.6-xen-sparse/drivers/xen/console/console.c	Sat Sep 02
15:23:32 2006 -0400
> +++ b/linux-2.6-xen-sparse/drivers/xen/console/console.c	Sat Sep 02
15:31:29 2006 -0400
> @@ -57,19 +57,27 @@
>  #include <asm/hypervisor.h>
>  #include <xen/evtchn.h>
>  #include <xen/xencons.h>
> +#include <xen/xenbus.h>
>  
>  /*
>   * Modes:
>   *  ''xencons=off''  [XC_OFF]:     Console is disabled.
>   *  ''xencons=tty''  [XC_TTY]:     Console attached to
''/dev/tty[0-9]+''.
>   *  ''xencons=ttyS'' [XC_SERIAL]:  Console attached to
''/dev/ttyS[0-9]+''.
> + *  ''xencons=xvc''  [XC_XVC]:     Console attached to
''/dev/xvc[0-9]+''.
>   *                 [XC_DEFAULT]: DOM0 -> XC_SERIAL ; all others ->
XC_TTY.
>   * 
>   * NB. In mode XC_TTY, we create dummy consoles for tty2-63. This
suppresses
>   * warnings from standard distro startup scripts.
>   */
> -static enum { XC_OFF, XC_DEFAULT, XC_TTY, XC_SERIAL } xc_mode =
XC_DEFAULT;
> +static enum { XC_OFF, XC_DEFAULT, XC_TTY, XC_SERIAL, XC_XVC } 
> +    xc_mode = XC_DEFAULT;
>  static int xc_num = -1;
> +
> +/* If we are in XC_XVC mode (a virtual console at /dev/xvcX), we need to
> + * comply with Lanana and use a minor under the low density serial major.
> + */
> +#define XEN_XVC_MINOR 187
>  
>  #ifdef CONFIG_MAGIC_SYSRQ
>  static unsigned long sysrq_requested;
> @@ -85,6 +93,8 @@ static int __init xencons_setup(char *st
>  		xc_mode = XC_SERIAL;
>  	else if (!strncmp(str, "tty", 3))
>  		xc_mode = XC_TTY;
> +	else if (!strncmp(str, "xvc", 3))
> +		xc_mode = XC_XVC;
>  	else if (!strncmp(str, "off", 3))
>  		xc_mode = XC_OFF;
>  
> @@ -95,6 +105,11 @@ static int __init xencons_setup(char *st
>  			xc_num = n;
>  		break;
>  	case XC_TTY:
> +		n = simple_strtol(str+3, &q, 10);
> +		if (q > (str + 3))
> +			xc_num = n;
> +		break;
> +	case XC_XVC:
There''s some code duplication here.
>  		n = simple_strtol(str+3, &q, 10);
>  		if (q > (str + 3))
>  			xc_num = n;
> @@ -194,11 +209,17 @@ static int __init xen_console_init(void)
>  		kcons_info.write = kcons_write_dom0;
>  	} else {
>  		if (xc_mode == XC_DEFAULT)
> -			xc_mode = XC_TTY;
> +			xc_mode = XC_XVC;
Not convinced we want to change the default until a little while after
the rest of the patch gets merged.
>  		kcons_info.write = kcons_write;
>  	}
>  
>  	switch (xc_mode) {
> +	case XC_XVC:
> +		strcpy(kcons_info.name, "xvc");
> +		if (xc_num == -1)
> +			xc_num = 0;
> +		break;
> +
>  	case XC_SERIAL:
>  		strcpy(kcons_info.name, "ttyS");
>  		if (xc_num == -1)
> @@ -265,7 +286,7 @@ void xencons_force_flush(void)
>  /******************** User-space console driver (/dev/console)
************/
>  
>  #define DRV(_d)         (_d)
> -#define DUMMY_TTY(_tty) ((xc_mode != XC_SERIAL) &&		\
> +#define DUMMY_TTY(_tty) ((xc_mode != XC_SERIAL) && (xc_mode !=
XC_XVC) && \
>  			 ((_tty)->index != (xc_num - 1)))
>  
>  static struct termios *xencons_termios[MAX_NR_CONSOLES];
> @@ -584,7 +605,8 @@ static int __init xencons_init(void)
>  
>  	xencons_ring_init();
>  
> -	xencons_driver = alloc_tty_driver((xc_mode == XC_SERIAL) ?
> +	xencons_driver = alloc_tty_driver(((xc_mode == XC_SERIAL) || 
> +					   (xc_mode == XC_XVC)) ?
>  					  1 : MAX_NR_CONSOLES);
>  	if (xencons_driver == NULL)
>  		return -ENOMEM;
> @@ -604,6 +626,11 @@ static int __init xencons_init(void)
>  		DRV(xencons_driver)->name        = "ttyS";
>  		DRV(xencons_driver)->minor_start = 64 + xc_num;
>  		DRV(xencons_driver)->name_base   = 0 + xc_num;
> +	} else if (xc_mode == XC_XVC) {
> +		DRV(xencons_driver)->name        = "xvc";
> +		DRV(xencons_driver)->major       = 250;
> +		DRV(xencons_driver)->minor_start = XEN_XVC_MINOR;
> +		DRV(xencons_driver)->name_base   = xc_num;
>  	} else {
>  		DRV(xencons_driver)->name        = "tty";
>  		DRV(xencons_driver)->minor_start = 1;
Steven.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Mon, 2006-09-04 at 10:01 +0100, Steven Smith wrote:
> > This is the patch from Amos Waterland for the xenconsole to
> > use /dev/xvc0 instead of taking over ttys.  I''ve fixed a few
places
> > which needed to check for XVC mode in addition to serial mode.  Also,
> > until LANANA responds with an official minor, I''ve adjusted
it to use
> > char 250/187 (in the experimental range) as opposed to 204/187.
> > 
> > (Should be identical to this patch from last time)
> Does this have anything to do with the virtual framebuffer work, or
> does it stand alone?
It stands alone, but without it, the framebuffer bits get a little
confusing to actually try to have used as the console.
> > @@ -194,11 +209,17 @@ static int __init xen_console_init(void)
> >  		kcons_info.write = kcons_write_dom0;
> >  	} else {
> >  		if (xc_mode == XC_DEFAULT)
> > -			xc_mode = XC_TTY;
> > +			xc_mode = XC_XVC;
> Not convinced we want to change the default until a little while after
> the rest of the patch gets merged.
The default *HAS* to be changed -- otherwise, the xvc console tries to
take over ttys (which is really really really wrong in the guest)

Jeremy


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> > > This is the patch from Amos Waterland for the xenconsole to
> > > use /dev/xvc0 instead of taking over ttys.  I''ve fixed a
few places
> > > which needed to check for XVC mode in addition to serial mode. 
Also,
> > > until LANANA responds with an official minor, I''ve
adjusted it to use
> > > char 250/187 (in the experimental range) as opposed to 204/187.
> > > 
> > > (Should be identical to this patch from last time)
> > Does this have anything to do with the virtual framebuffer work, or
> > does it stand alone?
> It stands alone, but without it, the framebuffer bits get a little
> confusing to actually try to have used as the console.
What goes wrong?
> > > @@ -194,11 +209,17 @@ static int __init xen_console_init(void)
> > >  		kcons_info.write = kcons_write_dom0;
> > >  	} else {
> > >  		if (xc_mode == XC_DEFAULT)
> > > -			xc_mode = XC_TTY;
> > > +			xc_mode = XC_XVC;
> > Not convinced we want to change the default until a little while after
> > the rest of the patch gets merged.
> The default *HAS* to be changed -- otherwise, the xvc console tries to
> take over ttys (which is really really really wrong in the guest)
So why have we survived this far without it?  If XC_TTY is completely
broken, why not remove it completely?

Steven.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, 2006-09-06 at 10:17 +0100, Steven Smith wrote:
> > > > This is the patch from Amos Waterland for the xenconsole to
> > > > use /dev/xvc0 instead of taking over ttys.  I''ve
fixed a few places
> > > > which needed to check for XVC mode in addition to serial
mode.  Also,
> > > > until LANANA responds with an official minor, I''ve
adjusted it to use
> > > > char 250/187 (in the experimental range) as opposed to
204/187.
> > > > 
> > > > (Should be identical to this patch from last time)
> > > Does this have anything to do with the virtual framebuffer work,
or
> > > does it stand alone?
> > It stands alone, but without it, the framebuffer bits get a little
> > confusing to actually try to have used as the console.
> What goes wrong?
xenconsole takes over ttys and although you can see the framebuffer with
the penguin and X will start, you can''t actually use the framebuffer as
a console :-)
> > > > @@ -194,11 +209,17 @@ static int __init
xen_console_init(void)
> > > >  		kcons_info.write = kcons_write_dom0;
> > > >  	} else {
> > > >  		if (xc_mode == XC_DEFAULT)
> > > > -			xc_mode = XC_TTY;
> > > > +			xc_mode = XC_XVC;
> > > Not convinced we want to change the default until a little while
after
> > > the rest of the patch gets merged.
> > The default *HAS* to be changed -- otherwise, the xvc console tries to
> > take over ttys (which is really really really wrong in the guest)
> So why have we survived this far without it?  If XC_TTY is completely
> broken, why not remove it completely?
We''ve survived this far because there isn''t anything else
which is
trying to use the console and this hack let people pretend they had
multiple vcs[1].  

Nuking it entirely is the right long-term answer, but giving people who
still depend on it an "out" for a little bit probably makes sense.
Although I could easily be convinced to just nuke it from orbit ;)

Jeremy

[1] Much in the same way that s390 does.. poorly ;-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> > > > > This is the patch from Amos Waterland for the
xenconsole to
> > > > > use /dev/xvc0 instead of taking over ttys. 
I''ve fixed a few places
> > > > > which needed to check for XVC mode in addition to
serial mode.  Also,
> > > > > until LANANA responds with an official minor,
I''ve adjusted it to use
> > > > > char 250/187 (in the experimental range) as opposed to
204/187.
> > > > > 
> > > > > (Should be identical to this patch from last time)
> > > > Does this have anything to do with the virtual framebuffer
work, or
> > > > does it stand alone?
> > > It stands alone, but without it, the framebuffer bits get a
little
> > > confusing to actually try to have used as the console.
> > What goes wrong?
> xenconsole takes over ttys and although you can see the framebuffer with
> the penguin and X will start, you can''t actually use the
framebuffer as
> a console :-)
Ack, got it now.  Forgive me for being a little slow.
> > > > > @@ -194,11 +209,17 @@ static int __init
xen_console_init(void)
> > > > >  		kcons_info.write = kcons_write_dom0;
> > > > >  	} else {
> > > > >  		if (xc_mode == XC_DEFAULT)
> > > > > -			xc_mode = XC_TTY;
> > > > > +			xc_mode = XC_XVC;
> > > > Not convinced we want to change the default until a little
while after
> > > > the rest of the patch gets merged.
> > > The default *HAS* to be changed -- otherwise, the xvc console
tries to
> > > take over ttys (which is really really really wrong in the guest)
> > So why have we survived this far without it?  If XC_TTY is completely
> > broken, why not remove it completely?
> We''ve survived this far because there isn''t anything else
which is
> trying to use the console and this hack let people pretend they had
> multiple vcs[1].  
Perhaps make this part #ifdef on CONFIG_XENFB at first?  It''ll be
easier to merge if it obviously doesn''t break any existing setup.

Steven.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi Jeremy.  The latest LANANA device list did not pick up my request for
204/187, giving that combination to Xilinx uartlite instead.  I am just
wondering if I should try again or if you are going to go with the
experimental range?


On Sat, Sep 02, 2006 at 03:58:50PM -0400, Jeremy Katz
wrote:
> This is the patch from Amos Waterland for the xenconsole to
> use /dev/xvc0 instead of taking over ttys.  I''ve fixed a few
places
> which needed to check for XVC mode in addition to serial mode.  Also,
> until LANANA responds with an official minor, I''ve adjusted it to
use
> char 250/187 (in the experimental range) as opposed to 204/187.
> 
> (Should be identical to this patch from last time)
> 
> Signed-off-by: Jeremy Katz <katzj@redhat.com>
> Cc: Amos Waterland <apw@us.ibm.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel