From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Pat Campbell" Subject: Re: PATCH: 0/10: Merge xenfb & xenconsoled into qemu-dm Date: Thu, 16 Aug 2007 10:13:02 -0600 Message-ID: <46C42150.3E48.0018.0@novell.com> References: <20070816124939.GA16779@redhat.com> <20070816153415.GH16779@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20070816153415.GH16779@redhat.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> On Thu, Aug 16, 2007 at 9:34 AM, in message <20070816153415.GH16779@redhat.com>, "Daniel P. Berrange" wrote:=20 > On Thu, Aug 16, 2007 at 01:54:04PM +0100, Keir Fraser wrote: >> On 16/8/07 13:49, "Daniel P. Berrange" wrote: >>=20 >> >> Are these patches intended to be applied now, or are they RFC? >> >=20 >> > They could be applied now, but was expecting people might have = some=20 > feedback >> > /recommendations for changes - Christian normally has lots of good = comments >> > for QEMU related stuff. So if I have to do another revision of the = patches >> > I'm fine with it. >>=20 >> My own feeling is that the xenfb merge is very sensible, but I don't = see >> much of a win from merging xenconsoled, and the downside is that you = then >> need a qemu- dm instance for every PV guest. I think that requiring = qemu- dm >> for more 'featureful' PV guests -- framebuffer, USB, etc -- is well = and >> good, but someone who is running more minimal domU configurations -- >> console, net, block -- isn't going to want or welcome the rather = unnecessary >> per- domU overhead of qemu- dm. >=20 > Yep, I can see that would be useful for some folks working in constrained= > environments. Of course they probably don't want the XenD overhead = either, > but that's a can of worms I won't get into right now ;- ) >=20 > 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. >=20 > Regards, > Dan. Would this patch set, in it's current state, allow a 'featureful' PV guest = to see a=20 DOM0 CDROM as a CD device instead of a block device? =20 Thanks Pat