From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Daniel P. Berrange" Subject: Re: PATCH: 0/10: Merge xenfb & xenconsoled into qemu-dm Date: Fri, 17 Aug 2007 21:12:28 +0100 Message-ID: <20070817201228.GD707@redhat.com> References: <20070816124939.GA16779@redhat.com> <20070816153415.GH16779@redhat.com> Reply-To: "Daniel P. Berrange" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20070816153415.GH16779@redhat.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Thu, Aug 16, 2007 at 04:34:15PM +0100, Daniel P. Berrange wrote: > On Thu, Aug 16, 2007 at 01:54:04PM +0100, Keir Fraser wrote: > > On 16/8/07 13:49, "Daniel P. Berrange" wrote: > > > > >> Are these patches intended to be applied now, or are they RFC? > > > > > > They could be applied now, but was expecting people might have some 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. > > > > 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. > > 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 ;-) > > 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//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 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 -=|