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: Alexander Graf
Subject: [Qemu-devel] Re: [PATCH 28/40] xenner: libxc emu: evtchn
Date: Mon, 1 Nov 2010 15:47:10 -0400

On 01.11.2010, at 15:41, Anthony Liguori wrote:

> On 11/01/2010 02:39 PM, Paolo Bonzini wrote:
>> On 11/01/2010 05:01 PM, Anthony Liguori wrote:
>>> 
>>> IIUC, this is a mini-libxc that you enable by mucking with
>>> LD_LIBRARY_PATH such that you can run things like xenstored unmodified.
>>> What I'm really asking is whether there has been a discussion about a
>>> more pleasant way to do this that the Xen guys would feel comfortable with.
>> 
>> I don't know if it's Alex or Gerd who did the switch, but this version of 
>> the code doesn't have the separate mini-libxc.  The code of the mini-libxc 
>> is embedded in QEMU, just like xenstored, blkback and netback.  See patch 
>> 31/40, which includes both the "mini xenstored" and the "mini libxenstore".
> 
> Oh, I'm still missing some of it.  That's a curious choice.
> 
> What's the logic for duplicating xenstored/xenconsoled?  I understand 
> blkback/netback.

Where else would it belong? Qemu is an emulator. Device emulation belongs to 
qemu code. The xen PV machine is nothing but a special case of the pc machine 
with custom firmware and odd devices :).

As I stated in my cover letter, the goal of all this should be to have the qemu 
pieces be 100% independent of any xen headers or libraries, so we can 
eventually isolate it well enough that it even works on non-x86. Then we're at 
the point qemu code usually is.

I'm sure there are also practical implications btw. But I don't really care 
about those too much, because the architectural ones outweigh that to me.


Alex




reply via email to

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