On Tue, Mar 15, 2011 at 01:42:56PM +0100, Jes Sorensen wrote: > On 03/14/11 17:40, Alon Levy wrote: > > On Mon, Mar 14, 2011 at 04:20:22PM +0100, Jes Sorensen wrote: > > > > ok, here is a note where I kinda ignored my own wishes but I want > > to be very clear on them: > > libcacard should not be part of qemu. > > it is here because I once thought it would speed things up. > > > > So I'm not taking it out or anything - it's fine with me that it > > goes into qemu, just as long as it's understood that I'm now maintaining > > another copy of it for usage outside of qemu, in the spice client (or > > any other client for that matter - it will be the same when we do vnc > > support for this). > > Hi Alon, > > This bit is somewhat problematic. If QEMU is maintaining a copy of > libcacard, then that has to comply with the QEMU way of doing things. > QEMU cannot rely on various portions in the tree behaving in different > ways. Otherwise it really should be an external library requirement > pulled in by the build. > > I am not sure what is the best way, if it stays in QEMU people will > eventually start making modifications to it, without looking at the > other copy that is being maintained. >
Yeah, I've already decided (actually minutes after sending this email) to go the route of keeping a copy of qemu-thread* in the external library, since the api is basically just a mirror of pthreads it was nothing but a few renames. > Alternatively the external apps that build against it should be taught > to link with the QEMU version. > That would require me to teach qemu's configure to build libcacard, possibly only libcacard (even though qemu doesn't need a lot of packages by itself, I still wouldn't want apt-get install spice-client to drag in qemu-kvm). > Cheers, > Jes
