[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] PATCH: 0/10: Merge xenfb & xenconsoled into qemu-dm


  • To: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Sat, 18 Aug 2007 11:11:20 +0100
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Sat, 18 Aug 2007 03:08:02 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcfhgB9EXaNgok1zEdyn3QAWy6hiGQ==
  • Thread-topic: [Xen-devel] PATCH: 0/10: Merge xenfb & xenconsoled into qemu-dm

On 17/8/07 21:12, "Daniel P. Berrange" <berrange@xxxxxxxxxx> wrote:

>> Thinking about this, I think I can easily re-work the last two patches so
>> that xenconsoled will continue to process the guest consoles, if-and-only-if
>> the guest doesn't have a QEMU instance already doing it. That would give us
>> choice between both deployment scenarios per-guest.
> 
> I've got this working ok - since both xenconsoled and qemu-dm are already
> reading the /local/domain/<id>/console/ path in xenstore, I simply added
> an extra field 'use-device-model' which can be 1 or 0. If XenD sees that
> a PV domain has a device model then it sets it to 1, causing xenconsoled
> to ignore that guest. I'll post patches to this effect over the weekend

Sounds basically good, but a field called 'type' in the backend xenstore
directory would be more flexible and more consistent with other backend
directory contents (at least netback's). We could use values 'ioemu' and
'xenconsoled', and absence of the field implies xenconsoled. Both ioemu and
xenconsoled should check the field.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.