All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arun Sharma <arun.sharma@intel.com>
To: Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>
Cc: Ian Pratt <Ian.Pratt@cl.cam.ac.uk>, xen-devel@lists.xensource.com
Subject: Re: [PATCH][1/10] Device model cleanup.
Date: Thu, 30 Jun 2005 11:42:17 -0700	[thread overview]
Message-ID: <42C43D09.3040801@intel.com> (raw)
In-Reply-To: <A95E2296287EAD4EB592B5DEEFCE0E9D28244A@liverpoolst.ad.cl.cam.ac.uk>

Ian Pratt wrote:

> This is useful progress, but I have a couple of comments/questions.
> 
> * should the empty config options be appearing in the sxp? I don't think
> so. Further, perhaps they should be wrapped in a (ioemu ...) section?
> 
> * we should make it such that disks can be specified using the same
> syntax as for normal paravirt drives e.g. file:, phy: etc.
>

Yes, will implement both of these.

> * I presume that the vncviewer is being forked from xm, but that the
> vncconect is being issued from xend, which is why it needs the $DISPLAY
> ?    

Rolf applied a patch sometime back that has two separate ways of connect 
a vncviewer to device models:

a) vncviewer -listen (port communicated to xend and then to qemu via 
-vncconnect). This is forked from xm.
b) libvncserver within qemu-dm (-vncport). This is forked from xend.

And then

c) the user may choose vnc=0 sdl=1.


It's really case (c) that requires $DISPLAY. Also, I think the end user 
needs only one of (a) and (b), not both. If $DISPLAY is not set in xm's 
environment, (a) will fail. In that sense (b) is more reliable.

> 
> * we still need some tests when building to ensure libvncserver and
> libsvg are installed. As the current behaviour when they're not is
> confusing -- I think its better to refuse to build ioemu if they're not
> installed.

Not all distributions are shipping libvncserver (for eg: FC4 didn't). 
Once we resolve that I think it's a reasonable thing to do.

> 
> * we should move qemu-dm from /usr/bin to /usr/lib/xen/bin
> 
> * files like mem-map.sxp should probably live in /usr/lib/xen/boot
>
> * presumably we no longer need bochsrc ?

Thanks for the comments. You should see some patches today.

	-Arun

  reply	other threads:[~2005-06-30 18:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-30  8:01 [PATCH][1/10] Device model cleanup Ian Pratt
2005-06-30 18:42 ` Arun Sharma [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-06-30 21:32 Ian Pratt
2005-06-30 19:28 Ian Pratt
2005-06-30 20:19 ` Arun Sharma
2005-06-30  5:50 Arun Sharma

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=42C43D09.3040801@intel.com \
    --to=arun.sharma@intel.com \
    --cc=Ian.Pratt@cl.cam.ac.uk \
    --cc=m+Ian.Pratt@cl.cam.ac.uk \
    --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.