qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [PATCH 28/40] xenner: libxc emu: evtchn


From: Paolo Bonzini
Subject: [Qemu-devel] Re: [PATCH 28/40] xenner: libxc emu: evtchn
Date: Mon, 01 Nov 2010 22:47:42 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100921 Fedora/3.1.4-1.fc13 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.4

On 11/01/2010 09:32 PM, Anthony Liguori wrote:

I'm not sure I agree with the goal.  I think where ever possible we
should reuse code with the Xen project when it makes sense.  Reusing
blkback/netback is impossible because we want userspace implementations
and the current implementations are in the kernel.  blktap also doesn't
tie into the QEMU block layer and making it tie into the QEMU block
layer would probably result in more code than it saved.

OTOH, xenstored and xenconsoled have very little direct dependence on
Xen.  I'm not saying that we shouldn't make things Just Work in QEMU, so
if that means spawning xenconsoled/xenstored automagically from QEMU
with special options, that's perfectly fine.

xenstored is 3 times bigger than what Alex submitted, however. The code is much simpler because _this_ xenstore only serves one domain. So it doesn't have to implement permissions, it doesn't have complicated threading to handle multiple instances of libxs accessing the daemon, and so on. Besides the data structures implementing the tree, there's really very little in common, and the xenner code is almost trivial.

The situation is similar for the console. There is only one console to track here. In fact, maybe it's simplest to implement it as a small 8250A driver in the xenner kernel, reading from the serial console at 0x3f8 and writing to the ring buffer and vice versa.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]