>>> On Thu, Aug 16, 2007 at 9:34 AM, in message
<20070816153415.GH16779@xxxxxxxxxx>, "Daniel P. Berrange" <berrange@xxxxxxxxxx>
wrote:
> On Thu, Aug 16, 2007 at 01:54:04PM +0100, Keir Fraser wrote:
>> On 16/8/07 13:49, "Daniel P. Berrange" <berrange@xxxxxxxxxx> 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.
>
> Regards,
> Dan.
Would this patch set, in it's current state, allow a 'featureful' PV guest to
see a
DOM0 CDROM as a CD device instead of a block device?
Thanks
Pat
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home