On Mon, Jan 22, 2007 at 02:46:11PM +0000, Mark McLoughlin wrote:
I've been very lame in not sending an update to these patches. I've updated them
to support TLS, protocol versioning, fixed size types on the wire & network
byte ordering on the wire. Shouldn't be too difficult to resolve though since I
think it'll only really impact your libvirt-network-qemu-stubs.patch file.
Based on IRC discussions I think we want to avoid both -std=gnu99 & -std=c99 from
the compiler flags. And just use appropriate feature macros like -D_XOPEN_SOURCE,
-D_SVID_SOURCE=1 as neccessary. In particular I'd like to avoid GNU specific bits
so we don't make life hard for Solaris / BSD guys.
Hmm, yeah I imagine the build patched that flag out because of its license issues.
I gues I'll have to make a 'configure' check to see if -no-kqemu is available
on a
particular host or not.
That should not be neccessary in my latest patches - I fixed up the transient
domain cleanup stuff in a slightly different way.
Looks good.
Already fixed in latest code.
Looks good, will merge that in my next QEMU patches.
Likewise, looks good.
Yep, we've lived with that baggage for too long
Seems reasonable.
On the note of cleanup - theres a bucket load of code in xml.c and xend_internal.c
which is never called by anything which we should remove - it constantly confuses
me when i work on these two files to see all this code which turns out to be unused.
Looks sane in principle. Not reviewed the code in detail yet.
This one is troublesome because of the ABI issue. It'll cause issues with the
virResetError, virCopyLastError, virConnCopyLastError functions, if the caller
passes in an object they allocated themselves.
The only way it would not be a problem is if we can ensure that virNetworkErr
never gets set unless the caller has called one of the virNetworkXXX functions,
because by calling those we can know for sure they've been compiled against a
recent set of headers. It'd be a nasty hack though.
Looks sane in principle. Not reviewed the code in detail yet.
Code looks sane, but will need a fixup to use fixed size types & network byte order.
Looks sane in principle. Not reviewed the code in detail yet.
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 -=|