All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Jeremy Katz <katzj@redhat.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Markus Armbruster <armbru@redhat.com>
Subject: Re: [PATCH] Paravirt framebuffer support in xend [3/5]
Date: Thu, 14 Sep 2006 20:27:32 +0100	[thread overview]
Message-ID: <20060914192732.GF2848@redhat.com> (raw)
In-Reply-To: <1157227117.11059.43.camel@aglarond.local>

On Sat, Sep 02, 2006 at 03:58:37PM -0400, Jeremy Katz wrote:
> Add support in xend and xm to know about the vnc and sdl options for PV
> domains.  Launch xen-sdlfb or xen-vncfb if we're setting up a graphics
> console.  Also, if we're going to use a graphical console in the guest,
> set /<dompath>/console/use_graphics to 1.

I've found a bit of a problematic interaction between the SEXPR for VNC
and bootloaders. The VNC related bit of the SEXPR is within the image
part, eg 

  (image 
    (linux 
       (kernel '/var/lib/xen/vmlinuz.RSa3-O')
       (ramdisk '/var/lib/xen/initrd.ndZEf8')
       (vnc 1)
       (vncdisplay 9)
    )
  )

If I'm using a bootloader though, the SEXPR I send to XenD does not even
contain a '(image (linux ...))' block so there is no place to specify the
VNC options. The hack of trying to supply a (image) section within a
kernel doesn't work:

  (bootloader '/usr/bin/pygrub')
  (image
    (linux 
       (vnc 1)
       (vncdisplay 9)
    )
  )


Because if XenD finds a 'image' node in the SEXPR it ignores the bootloader
settings & assumes there is a (kernel) bit. Now we could hack it so that
XenD can handle a (image) bit without a kernel specified, but really this
is far from optimal. 

IMHO the VNC console options have no business being anywhere near the (image)
bit of the SEXPR since they're nothing todo with kernel images whatsoever.
Of course I understand why the PV framebuffer puts them here - its just
copying existing HVM style, but that doesn't make it a good idea. I think
we'd be better off having the framebuffer related stuff as a fully-fledged
part of the (device) SEXPR block.

So this raises two questions, do we want to re-arrange the SEXPR to have
VNC opts in a sensible part, or is there a way we can make existing scheme
work nicely with bootloaders.


NB, the reason that 'xm' can create domains with the framebuffer active,
and using the bootloader is because xm runs 'pygrub' client side& then
munges the SEXPR before sending it to XenD. The problem occurrs only if
you are running pygrub server-side (ie letting XenD run it) because then
there is no way to specify any console options due to missing (image)
block.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

      parent reply	other threads:[~2006-09-14 19:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-02 19:58 [PATCH] Paravirt framebuffer support in xend [3/5] Jeremy Katz
2006-09-04  9:02 ` Steven Smith
2006-09-05 16:11   ` Jeremy Katz
2006-09-06  9:17     ` Steven Smith
2006-09-06 11:43       ` sos22-xen
2006-09-06 13:59       ` Jeremy Katz
2006-09-07  8:01         ` Steven Smith
2006-09-14 19:27 ` Daniel P. Berrange [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060914192732.GF2848@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=katzj@redhat.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.