console questions

console questions

[Aron Griffis]

A couple questions regarding xvc...

1. xencons=xvc works and makes more sense than clobbering ttyS0 by
   default.  Is there some reason that the default for xencons is
   still ttyS on dom0?  Sure hvc is coming, but would it be reasonable
   to change the default for xencons in the meantime?

2. xencons=xvc1 and upward is accepted by the kernel, but it just
   changes the userland naming.  The major/minor remains the same at
   204/191.  What's the point of this?  Is there any reason to allow
   anything other than xencons=xvc or xencons=xvc0?

Thanks,
Aron

Re: console questions

[Keir Fraser]

On 6/8/07 22:29, "Aron Griffis" <aron@hp.com> wrote:

> 1. xencons=xvc works and makes more sense than clobbering ttyS0 by
>    default.  Is there some reason that the default for xencons is
>    still ttyS on dom0?  Sure hvc is coming, but would it be reasonable
>    to change the default for xencons in the meantime?

Now done for dom0 and domU. Users will need to change their inittab to getty
xvc0, or need to place 'xencons=tty' on their kernel command line.

> 2. xencons=xvc1 and upward is accepted by the kernel, but it just
>    changes the userland naming.  The major/minor remains the same at
>    204/191.  What's the point of this?  Is there any reason to allow
>    anything other than xencons=xvc or xencons=xvc0?

What's the better alternative? Needlessly penalise a typo?

 -- Keir

Re: console questions

[Aron Griffis]

Keir Fraser wrote:  [Tue Aug 07 2007, 03:59:42AM EDT]
> On 6/8/07 22:29, "Aron Griffis" <aron@hp.com> wrote:
> 
> > 1. xencons=xvc works and makes more sense than clobbering ttyS0 by
> >    default.  Is there some reason that the default for xencons is
> >    still ttyS on dom0?  Sure hvc is coming, but would it be reasonable
> >    to change the default for xencons in the meantime?
> 
> Now done for dom0 and domU. Users will need to change their inittab to getty
> xvc0, or need to place 'xencons=tty' on their kernel command line.

Thanks, that's great.  I am mystified by something though: How is
/dev/console hooked up to /dev/xvc0 by default?  If I boot dom0 and
omit both xencons and console kernel parameters, /dev/console is
clearly being hooked up to /dev/xvc0.  But I'm not seeing how this
happens.

In fact, arch/ia64/kernel/setup.c assumes that the default for
xencons is ttyS and calls add_preferred_console("ttyS", 0, NULL);
I would expect this to break things, but somehow it doesn't.  This
makes me wonder if that code is necessary at all.

> > 2. xencons=xvc1 and upward is accepted by the kernel, but it just
> >    changes the userland naming.  The major/minor remains the same at
> >    204/191.  What's the point of this?  Is there any reason to allow
> >    anything other than xencons=xvc or xencons=xvc0?
> 
> What's the better alternative? Needlessly penalise a typo?

I wasn't suggesting castigation...  Mostly I wanted to understand if
there was a hidden reason for supporting xvc1 and higher.  The fact
that xencons=xvc1 will make the console show up in a different place
makes distro support more interesting.

Aron

Re: console questions

[Aron Griffis]

Alex,

linux-2.6.18-xen.hg cset 153:12c399692d44 changed the xencons default
to xvc for both dom0 and domU.  I believe this ia64 patch is
appropriate though I'm slightly unsure because everything seems to
work correctly, even without it!  Nonetheless, I built and boot-tested
dom0 with this patch.

Signed-off-by: Aron Griffis <aron@hp.com>

# HG changeset patch
# User Aron Griffis <aron@hp.com>
# Date 1186527819 14400
# Node ID 99297c7bc9d945f3a902db9324efae438c64e316
# Parent  840b9df48b6a4f0f569963dba01885bde2946b6b
xencons default is now xvc for dom0/domU

diff -r 840b9df48b6a -r 99297c7bc9d9 arch/ia64/kernel/setup.c
--- a/arch/ia64/kernel/setup.c	Tue Aug 07 09:37:41 2007 +0100
+++ b/arch/ia64/kernel/setup.c	Tue Aug 07 19:03:39 2007 -0400
@@ -560,17 +560,12 @@ setup_arch (char **cmdline_p)
 		
 		/*
 		 * If a console= is NOT specified, we assume using the
-		 * xencons console is desired.  By default, this is ttyS0
-		 * for dom0 and tty0 for domU.
+		 * xencons console is desired.  By default this is xvc0 
+		 * for both dom0 and domU
 		 */
 		if (!strstr(*cmdline_p, "console=")) {
-			char *p, *q, name[5];
+			char *p, *q, name[5] = "xvc";
 			int offset = 0;
-
-			if (is_initial_xendomain())
-				strncpy(name, "ttyS", 4);
-			else
-				strncpy(name, "tty", 3);
 
 			p = strstr(*cmdline_p, "xencons=");

Re: console questions

[Keir Fraser]

This goes into the ia64 tree, if it's to be applied.

 K.

On 8/8/07 00:17, "Aron Griffis" <aron@hp.com> wrote:

> Alex,
> 
> linux-2.6.18-xen.hg cset 153:12c399692d44 changed the xencons default
> to xvc for both dom0 and domU.  I believe this ia64 patch is
> appropriate though I'm slightly unsure because everything seems to
> work correctly, even without it!  Nonetheless, I built and boot-tested
> dom0 with this patch.
> 
> Signed-off-by: Aron Griffis <aron@hp.com>
> 
> # HG changeset patch
> # User Aron Griffis <aron@hp.com>
> # Date 1186527819 14400
> # Node ID 99297c7bc9d945f3a902db9324efae438c64e316
> # Parent  840b9df48b6a4f0f569963dba01885bde2946b6b
> xencons default is now xvc for dom0/domU
> 
> diff -r 840b9df48b6a -r 99297c7bc9d9 arch/ia64/kernel/setup.c
> --- a/arch/ia64/kernel/setup.c Tue Aug 07 09:37:41 2007 +0100
> +++ b/arch/ia64/kernel/setup.c Tue Aug 07 19:03:39 2007 -0400
> @@ -560,17 +560,12 @@ setup_arch (char **cmdline_p)
> 
> /*
> * If a console= is NOT specified, we assume using the
> -   * xencons console is desired.  By default, this is ttyS0
> -   * for dom0 and tty0 for domU.
> +   * xencons console is desired.  By default this is xvc0
> +   * for both dom0 and domU
> */
> if (!strstr(*cmdline_p, "console=")) {
> -   char *p, *q, name[5];
> +   char *p, *q, name[5] = "xvc";
> int offset = 0;
> -
> -   if (is_initial_xendomain())
> -    strncpy(name, "ttyS", 4);
> -   else
> -    strncpy(name, "tty", 3);
>  
> p = strstr(*cmdline_p, "xencons=");
>  
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: console questions

[Alex Williamson]

On Tue, 2007-08-07 at 19:17 -0400, Aron Griffis wrote:
> Alex,
> 
> linux-2.6.18-xen.hg cset 153:12c399692d44 changed the xencons default
> to xvc for both dom0 and domU.  I believe this ia64 patch is
> appropriate though I'm slightly unsure because everything seems to
> work correctly, even without it!  Nonetheless, I built and boot-tested
> dom0 with this patch.

Aron,

   Please rework against current ia64/linux-2.6.18-xen.hg, there have
been a few changes, in this area.  The VGA console set by the PCDP
parsing needs to be accounted for.  Thanks,

	Alex

-- 
Alex Williamson                             HP Open Source & Linux Org.

Re: console questions

[Alex Williamson]

On Wed, 2007-08-08 at 21:06 -0600, Alex Williamson wrote:
>    Please rework against current ia64/linux-2.6.18-xen.hg, there have
> been a few changes, in this area.  The VGA console set by the PCDP
> parsing needs to be accounted for.  Thanks,

Hi Aron,

   I merged the ia64 trees with upstream and created a patch based on
this one to default ia64 to using vxc for the console.  Please let me
know if you see any problems.  For everyone else, please make note of
this change and use xencons= to override to previous behavior or update
your inittab to use the new console.  Thanks,

	Alex

-- 
Alex Williamson                             HP Open Source & Linux Org.

Re: console questions

[Keir Fraser]

On 7/8/07 22:37, "Aron Griffis" <aron@hp.com> wrote:

> Thanks, that's great.  I am mystified by something though: How is
> /dev/console hooked up to /dev/xvc0 by default?  If I boot dom0 and
> omit both xencons and console kernel parameters, /dev/console is
> clearly being hooked up to /dev/xvc0.  But I'm not seeing how this
> happens.
> 
> In fact, arch/ia64/kernel/setup.c assumes that the default for
> xencons is ttyS and calls add_preferred_console("ttyS", 0, NULL);
> I would expect this to break things, but somehow it doesn't.  This
> makes me wonder if that code is necessary at all.

It isn't because we assert CON_ENABLED in our console-info structure. This
means it prints console output even without a 'console=' line. All I had to
change was inittab and securetty to getty on xvc0 and allow root login on
xvc0.

 -- Keir

>>> 2. xencons=xvc1 and upward is accepted by the kernel, but it just
>>>    changes the userland naming.  The major/minor remains the same at
>>>    204/191.  What's the point of this?  Is there any reason to allow
>>>    anything other than xencons=xvc or xencons=xvc0?
>> 
>> What's the better alternative? Needlessly penalise a typo?
> 
> I wasn't suggesting castigation...  Mostly I wanted to understand if
> there was a hidden reason for supporting xvc1 and higher.  The fact
> that xencons=xvc1 will make the console show up in a different place
> makes distro support more interesting.