[A bit of context restored]
Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> writes:
> On 12/11/06 2:20 pm, "Steven Smith" <sos22-xen@xxxxxxxxxxxxx> wrote:
>
diff -rupN -x '*.orig' linux-2.6.16.29-xen/drivers/xen/console/console.c
linux-2.6.16.29-xen-vfb/drivers/xen/console/console.c
--- linux-2.6.16.29-xen/drivers/xen/console/console.c 2006-09-29
16:11:51.000000000 +0200
+++ linux-2.6.16.29-xen-vfb/drivers/xen/console/console.c 2006-11-10
09:43:37.000000000 +0100
@@ -195,12 +210,23 @@ static int __init xen_console_init(void)
} else {
if (!xen_start_info->console.domU.evtchn)
goto out;
- if (xc_mode == XC_DEFAULT)
- xc_mode = XC_TTY;
>>> +#ifdef CONFIG_XEN_FRAMEBUFFER
>>> + xc_mode = XC_XVC;
>>> +#else
>>> + xc_mode = XC_TTY;
>>> +#endif
>>> + }
>> This hunk is changing the default behaviour of xencons in domU from
>> registering as tty{0...} to registering as xvc{0...}, yes? That's
>> going to confuse a lot of people with existing domUs which have gettys
>> etc. set up on /dev/ttyX but not /dev/xvcX.
>
> We're waiting to hear from lanana before switching to xvc. I re-submitted
> the allocation request two weeks ago (31st October). I haven't heard
> anything yet. I suppose since static device nodes in /dev are rare these
> days (since everyone moved to udev) we can just squat on some device number
> for the time being, or settle for requesting a dynamic one at boot time and
> require use of udev for anyone who cares about the device node. We already
> settled for that with /dev/xen/evtchn, for example.
What do you want me to do here for the short term? Drop the patch
hunk and let you sort it out?
Please mind the discussion we had some time ago, most relevant message
appended.
From: Steven Smith <sos22-xen@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Paravirt framebuffer use xvc as console [4/5]
To: Jeremy Katz <katzj@xxxxxxxxxx>
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>,
Markus Armbruster <armbru@xxxxxxxxxx>, sos22@xxxxxxxxxxxxx,
Amos Waterland <apw@xxxxxxxxxx>
Date: Wed, 6 Sep 2006 22:17:13 +0100
> > > > > 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home