This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] console questions

To: Aron Griffis <aron@xxxxxx>
Subject: Re: [Xen-devel] console questions
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Wed, 08 Aug 2007 08:16:45 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 08 Aug 2007 00:10:31 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070807213658.GB12998@xxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcfZjBOMUgU3nkV/EdyzVwAWy6hiGQ==
Thread-topic: [Xen-devel] console questions
User-agent: Microsoft-Entourage/
On 7/8/07 22:37, "Aron Griffis" <aron@xxxxxx> 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

 -- 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.

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>