[libvirt] read-only git mirror of cvs libvirt-java repo
A libvirt-java git mirror is in place: Browse change-sets via the web (gitweb): http://git.et.redhat.com/?p=libvirt-java.git;a=summary check out a copy of the repository with this command: git clone git://git.et.redhat.com/libvirt-java -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Generic internal API for network XML parser/formatter
Daniel P. Berrange [EMAIL PROTECTED] wrote:
We currently have two drivers which handle the networking XML containing
duplicated parsers and formatters for the XML, and very similar structs.
This patch introduces a new general purpose internal API for parsing and
formatting network XML, and representing it as a series of structs.
This code is derived from the current equivalent code in the QEMU driver
for networks.
The naming conventions I'm adopting in this patch follow those in the
storage driver:
- virNetworkPtr - the public opaque object in libvirt.h
- virNetworkObjPtr - the primary internal object for network state
- virNetworkDefPtr - the configuration data for a network
A virNetworkObjPtr contains a reference to one or two virNetworkDefPtr
objects - the current live config, and potentially a secondary inactive
config which will become live at the next restart.
The structs are defined in network_conf.h, along with a bunch of APIs for
dealing with them. These APIs are the same as similarly named ones from
the current qemu driver, but I'll go over them again for a reminder:
virNetworkObjPtr virNetworkFindByUUID(const virNetworkObjPtr nets,
const unsigned char *uuid);
virNetworkObjPtr virNetworkFindByName(const virNetworkObjPtr nets,
const char *name);
Allow lookup of a virNetworkObjPtr object based on its name or UUID, as
typically obtained from the public virNetworkPtr object.
The 'nets' parameter to both of thse is a linked list of networks which
are currently known to the driver using this API.
...
Thanks for writing those descriptions. When you write so much code,
I'm reluctant to say anything about comment density, but I was surprised
to see the same functions defined below with no comment saying what each
does. It'd be nice to copy each of the above into a function-describing
comment.
diff -r a6e5acdd23df src/Makefile.am
--- a/src/Makefile.am Tue Jun 24 15:07:21 2008 +0100
+++ b/src/Makefile.am Tue Jun 24 15:07:23 2008 +0100
@@ -52,6 +52,7 @@
driver.h\
proxy_internal.c proxy_internal.h \
conf.c conf.h \
+network_conf.c network_conf.h \
leading spaces in Makefile.am is technically ok in this context,
but it's inconsistent with the neighboring lines.
xm_internal.c xm_internal.h \
remote_internal.c remote_internal.h \
bridge.c bridge.h \
diff -r a6e5acdd23df src/network_conf.c
...
+++ b/src/network_conf.c Tue Jun 24 15:07:23 2008 +0100
@@ -0,0 +1,467 @@
+/*
+ * network_conf.h: network XML handling
s/\.h/.c/ This is a good reason not to put the name
of the file in a comment inside the file itself.
...
+static int
+virNetworkDHCPRangeDefParseXML(virConnectPtr conn,
+ virNetworkDefPtr def,
+ xmlNodePtr node) {
+
+xmlNodePtr cur;
+
+cur = node-children;
+while (cur != NULL) {
+xmlChar *start, *end;
+
+if (cur-type != XML_ELEMENT_NODE ||
+!xmlStrEqual(cur-name, BAD_CAST range)) {
+cur = cur-next;
+continue;
+}
+
+if (!(start = xmlGetProp(cur, BAD_CAST start))) {
+cur = cur-next;
+continue;
+}
+if (!(end = xmlGetProp(cur, BAD_CAST end))) {
+cur = cur-next;
+xmlFree(start);
+continue;
+}
+
+if (VIR_REALLOC_N(def-ranges, def-nranges + 1) 0) {
+xmlFree(start);
+xmlFree(end);
+virNetworkReportError(conn, VIR_ERR_NO_MEMORY, NULL);
+return -1;
+}
+def-ranges[def-nranges].start = (char *)start;
+def-ranges[def-nranges].end = (char *)end;
+def-nranges++;
+
+cur = cur-next;
+}
+
+return 0;
+}
With four cur = cur-next; statements, I prefer a for-loop.
And rather than all the if-negated-condition-then-continue, I find the
positive-cond tests to be more readable. Here's an untested alternative
that should be equivalent:
static int
virNetworkDHCPRangeDefParseXML(virConnectPtr conn,
virNetworkDefPtr def,
xmlNodePtr node)
{
xmlNodePtr cur;
for (cur = node-children; cur != NULL; cur = cur-next) {
xmlChar *start, *end = NULL;
if (!(cur-type == XML_ELEMENT_NODE
xmlStrEqual(cur-name, BAD_CAST range))
continue;
if ((start = xmlGetProp(cur, BAD_CAST start))
(end = xmlGetProp(cur, BAD_CAST end))) {
if (VIR_REALLOC_N(def-ranges, def-nranges + 1) 0) {
xmlFree(start);
[libvirt] Release of libvirt-java-0.1.1
A new release which should fix the main portability problems (crossing fingers) and add the authentication support patch from Tóth István. Available at ftp://libvirt.org/libvirt/java/ Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: virt-console
On Tue, Jul 01, 2008 at 04:21:38PM +0100, John Levon wrote: See implementation here: http://cr.opensolaris.org/~johnlev/virt-console/ (inside libvirt.hg/patches/libvirt/virt-console) Hum :-) ++ * Daniel Berrange [EMAIL PROTECTED] ++ * ++ * Copyright 2008 Sun Microsystems, Inc. All rights reserved. This splits virsh console into a separate binary to allow it to be setuid-root on Solaris (where we check permissions then drop privilege). It also fixes a number of RFEs This is against 0.4.0, so it's not ready for merging yet (I hope to get it forward ported at some point). I may be mistaken but this seems to basically be limited to console for domains running on the local machine, and hum, I doubt it's really a good approach. Seems to me it's better to talk to the vnc (or other protocol used to connect remotely) export of the console, and get rid of the 'localhost only' limitation. But I may very well have missed something. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: virt-console
On Tue, Jul 01, 2008 at 11:56:25AM -0400, Daniel Veillard wrote: On Tue, Jul 01, 2008 at 04:21:38PM +0100, John Levon wrote: See implementation here: http://cr.opensolaris.org/~johnlev/virt-console/ (inside libvirt.hg/patches/libvirt/virt-console) Hum :-) ++ * Daniel Berrange [EMAIL PROTECTED] ++ * ++ * Copyright 2008 Sun Microsystems, Inc. All rights reserved. What? This splits virsh console into a separate binary to allow it to be setuid-root on Solaris (where we check permissions then drop privilege). It also fixes a number of RFEs This is against 0.4.0, so it's not ready for merging yet (I hope to get it forward ported at some point). I may be mistaken but this seems to basically be limited to console for domains running on the local machine, and hum, I doubt it's really a good approach. This is an incremental improvement over what exists in the current code (and indeed, is a partially a response to code review comments from Dan). It's not reasonable to expect me to go off and implement something else altogether (a remote console server). regards john -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: virt-console
On Tue, Jul 01, 2008 at 11:56:25AM -0400, Daniel Veillard wrote: On Tue, Jul 01, 2008 at 04:21:38PM +0100, John Levon wrote: See implementation here: http://cr.opensolaris.org/~johnlev/virt-console/ (inside libvirt.hg/patches/libvirt/virt-console) Hum :-) ++ * Daniel Berrange [EMAIL PROTECTED] ++ * ++ * Copyright 2008 Sun Microsystems, Inc. All rights reserved. This splits virsh console into a separate binary to allow it to be setuid-root on Solaris (where we check permissions then drop privilege). It also fixes a number of RFEs This is against 0.4.0, so it's not ready for merging yet (I hope to get it forward ported at some point). I may be mistaken but this seems to basically be limited to console for domains running on the local machine, and hum, I doubt it's really a good approach. Seems to me it's better to talk to the vnc (or other protocol used to connect remotely) export of the console, and get rid of the 'localhost only' limitation. But I may very well have missed something. This is the same limitation as the existing 'virsh console' - John's merely splitting it into a separate binary, which is what I previously suggested for making the solaris privilege separation work better in the context of virsh. It is also only intended to be used for the text console - we've already got perfectly good clients for the remote graphical VNC console. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Generic internal API for network XML parser/formatter
Daniel P. Berrange [EMAIL PROTECTED] wrote:
...
diff -r a6e5acdd23df src/network_conf.h
...
+/* 2 possible types of forwarding */
+enum virNetworkForwardType {
+VIR_NETWORK_FORWARD_NONE = 0,
+VIR_NETWORK_FORWARD_NAT,
+VIR_NETWORK_FORWARD_ROUTE,
+
+VIR_NETWORK_FORWARD_LAST,
+};
+
+typedef struct _virNetworkDHCPRangeDef virNetworkDHCPRangeDef;
+typedef virNetworkDHCPRangeDef *virNetworkDHCPRangeDefPtr;
+struct _virNetworkDHCPRangeDef {
+char *start;
+char *end;
+};
+
+typedef struct _virNetworkDef virNetworkDef;
+typedef virNetworkDef *virNetworkDefPtr;
+struct _virNetworkDef {
+unsigned char uuid[VIR_UUID_BUFLEN];
+char *name;
+
+char *bridge; /* Name of bridge device */
+int stp : 1; /* Spanning tree protocol */
+long delay; /* Bridge forward delay (ms) */
It looks like delay can only be non-negative, so unsigned long would work.
The only change that'd have to accompany it would be s/%ld/%lu/
in a printf format string.
+int forwardType;/* One of virNetworkForwardType constants */
How about using enum virNetworkForwardType?
Nicer for debugging.
+char *forwardDev; /* Destination device for forwarding */
+
+char *ipAddress;/* Bridge IP address */
+char *netmask;
+char *network;
+
+int nranges;/* Zero or more dhcp ranges */
This is never negative, so could be unsigned int.
...
+struct _virNetworkObj {
+int dnsmasqPid;
How about pid_t?
+unsigned int active : 1;
+unsigned int autostart : 1;
+unsigned int persistent : 1;
+
+char *configFile;/* Persistent config file path */
+char *autostartLink; /* Symlink path for autostart */
+
+virNetworkDefPtr def; /* The current definition */
+virNetworkDefPtr newDef; /* New definition to activate at shutdown */
+
+virNetworkObjPtr next;
+};
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: virt-console
On Tue, Jul 01, 2008 at 05:49:34PM +0100, John Levon wrote: On Tue, Jul 01, 2008 at 11:56:25AM -0400, Daniel Veillard wrote: On Tue, Jul 01, 2008 at 04:21:38PM +0100, John Levon wrote: See implementation here: http://cr.opensolaris.org/~johnlev/virt-console/ (inside libvirt.hg/patches/libvirt/virt-console) Hum :-) ++ * Daniel Berrange [EMAIL PROTECTED] ++ * ++ * Copyright 2008 Sun Microsystems, Inc. All rights reserved. What? Well I found that a bit strange, if Daniel Berrange wrote it I doubt the copyright would be Sun Microsystem, and vice-versa, maybe there is an author missing or something. This splits virsh console into a separate binary to allow it to be setuid-root on Solaris (where we check permissions then drop privilege). It also fixes a number of RFEs This is against 0.4.0, so it's not ready for merging yet (I hope to get it forward ported at some point). I may be mistaken but this seems to basically be limited to console for domains running on the local machine, and hum, I doubt it's really a good approach. This is an incremental improvement over what exists in the current code (and indeed, is a partially a response to code review comments from Dan). It's not reasonable to expect me to go off and implement something else altogether (a remote console server). okay, I wasn't sure it was the plan and I was asking. As Dan pointed out it's the right approach, okay, I'm just surprized. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: virt-console
On Tue, Jul 01, 2008 at 01:52:01PM -0400, Daniel Veillard wrote: See implementation here: http://cr.opensolaris.org/~johnlev/virt-console/ (inside libvirt.hg/patches/libvirt/virt-console) Hum :-) ++ * Daniel Berrange [EMAIL PROTECTED] ++ * ++ * Copyright 2008 Sun Microsystems, Inc. All rights reserved. What? Well I found that a bit strange, if Daniel Berrange wrote it I doubt the copyright would be Sun Microsystem, and vice-versa, maybe there is an author missing or something. Dan wrote the original code, and I made significant changes. Thus, Dan's copyright and author comment, followed by Sun's. Sun, as a matter of policy, don't include author information in source code. If there's some clearer way of doing this you can think of, let me know. Dan). It's not reasonable to expect me to go off and implement something else altogether (a remote console server). okay, I wasn't sure it was the plan and I was asking. As Dan pointed out it's the right approach, okay, I'm just surprized. To be clear, we'd love to see a remote console implementation happen, it's just not a priority for us right now. regards, john -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: virt-console
On Tue, Jul 01, 2008 at 07:00:51PM +0100, John Levon wrote: On Tue, Jul 01, 2008 at 01:52:01PM -0400, Daniel Veillard wrote: See implementation here: http://cr.opensolaris.org/~johnlev/virt-console/ (inside libvirt.hg/patches/libvirt/virt-console) Hum :-) ++ * Daniel Berrange [EMAIL PROTECTED] ++ * ++ * Copyright 2008 Sun Microsystems, Inc. All rights reserved. What? Well I found that a bit strange, if Daniel Berrange wrote it I doubt the copyright would be Sun Microsystem, and vice-versa, maybe there is an author missing or something. Dan wrote the original code, and I made significant changes. Thus, Dan's copyright and author comment, followed by Sun's. Sun, as a matter of policy, don't include author information in source code. If there's some clearer way of doing this you can think of, let me know. Just move the Copyright statement up a few lines in the source file so its directly below the existing Copyright statement in the file. Dan). It's not reasonable to expect me to go off and implement something else altogether (a remote console server). okay, I wasn't sure it was the plan and I was asking. As Dan pointed out it's the right approach, okay, I'm just surprized. To be clear, we'd love to see a remote console implementation happen, it's just not a priority for us right now. Newer QEMU also supports the 'telnet' protocol, so we might be better off just telling people to use a telnet client, and keep this for local only PTY based console access. Of course you're using Xen with libvirt, so it'd probably require Xen to port to the newer QEMU codebase before that's an option for you. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: virt-console
On Tue, Jul 01, 2008 at 07:14:04PM +0100, Daniel P. Berrange wrote: okay, I wasn't sure it was the plan and I was asking. As Dan pointed out it's the right approach, okay, I'm just surprized. To be clear, we'd love to see a remote console implementation happen, it's just not a priority for us right now. Newer QEMU also supports the 'telnet' protocol, so we might be better off just telling people to use a telnet client, and keep this for local only PTY based console access. Indeed, this is what we're doing for debugging purposes, and it already works (for HVM only). But of course it's not secure yet, so it's really no better than just sshing to run virsh console locally. regards john -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: virt-console
On Tue, Jul 01, 2008 at 07:26:44PM +0100, John Levon wrote: On Tue, Jul 01, 2008 at 07:14:04PM +0100, Daniel P. Berrange wrote: okay, I wasn't sure it was the plan and I was asking. As Dan pointed out it's the right approach, okay, I'm just surprized. To be clear, we'd love to see a remote console implementation happen, it's just not a priority for us right now. Newer QEMU also supports the 'telnet' protocol, so we might be better off just telling people to use a telnet client, and keep this for local only PTY based console access. Indeed, this is what we're doing for debugging purposes, and it already works (for HVM only). But of course it's not secure yet, so it's really no better than just sshing to run virsh console locally. I've no idea just how much work it'd be, but IIRC there is a telnet extension to layer in Kerberos for both auth session encryption. Might be something to think about in the future, since it'd allow secure console access without having to give out a shell account on the host machine Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: virt-console
On Tue, Jul 01, 2008 at 07:35:56PM +0100, Daniel P. Berrange wrote:
http://cr.opensolaris.org/~johnlev/virt-console/
--- libvirt-0.4.0/src/Makefile.in 2008-06-27 06:17:20.865621099 -0700
+++ libvirt-1/src/Makefile.in 2008-06-27 06:19:55.983265305 -0700
You can exclude Makefile.in from patches, since its auto-generated.
Yes, I know, but not for our bits (long story, hopefully fixed soon).
+char *argv[] = { /usr/bin/virt-console, NULL, NULL, NULL, NULL };
This should probably be
char *argv[] = { BINDIR /virt-console, NULL, NULL, NULL, NULL };
so that it auto-adjusts when people pass --prefix to configure
Sure.
+waitpid(pid, NULL, 0);
Ought to do this in a while loop to handle EINTR.
OK, although I'm not sure it really matters here?
--- /dev/null 2008-06-30 17:03:12.0 -0700
+++ libvirt-new/src/virt-console.c 2008-06-30 16:58:36.079071463 -0700
I'd prefer to keep the source in the 'console.c' file instead of renaming
it, just to make historical diff tracking a little easier.
Really? Surely even subversion can do cross-rename tracking OK?
+*conn = virConnectOpenAuth(conn_name, virConnectAuthPtrDefault, 0);
We ought to pass VIR_CONNECT_RO as the 3rd arg here, since the console
doesn't require write access.
OK.
The virXPathString() method from xml.h will simplify the following handling
Can use virStrToLong_i from util.h here.
The perils of borrowing code, everyone wants to clean it up. Sure :)
I think we probably need to wait a little longer than this - 5 times with a
1 second sleep perhaps. Under heavy load it can take a while for reboot to
complete
Yeah, you might be right. Though it's possible to break even this most
likely.
I like the support for re-connecting after reboot. At the same time I
wonder if we need to make the an optional command line flag. Some apps
using virsh console, may rely on the fact that it exits when a VM
shuts down.
I hate --behave-like-you-should flags and will do everything I can to
avoid them. Let's not inconvenience everybody for the sake of some
possible breakage. The perils of people coding to human interfaces. (I
wanted to make --verbose the default, like telnet, but that seemed much
more likely to break someone's scripts).
I'm not adverse to a disconnect-on-shutdown flag, if people think it
would be useful, which would at least make any such breakage that might
exist easy to fix.
Thanks for the review Dan.
regards,
john
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: virt-console
On Tue, Jul 01, 2008 at 07:50:02PM +0100, John Levon wrote: On Tue, Jul 01, 2008 at 07:35:56PM +0100, Daniel P. Berrange wrote: --- /dev/null 2008-06-30 17:03:12.0 -0700 +++ libvirt-new/src/virt-console.c2008-06-30 16:58:36.079071463 -0700 I'd prefer to keep the source in the 'console.c' file instead of renaming it, just to make historical diff tracking a little easier. Really? Surely even subversion can do cross-rename tracking OK? We're using CVS for libvirt yes it sucks :-) I like the support for re-connecting after reboot. At the same time I wonder if we need to make the an optional command line flag. Some apps using virsh console, may rely on the fact that it exits when a VM shuts down. I hate --behave-like-you-should flags and will do everything I can to avoid them. Let's not inconvenience everybody for the sake of some possible breakage. The perils of people coding to human interfaces. (I wanted to make --verbose the default, like telnet, but that seemed much more likely to break someone's scripts). I'm mostly concerned about 'virsh console' - we only need to keep compatability for that. The standalone virt-console can have the auto-track restarts syntax and we can recommend use for virt-console as the primary tool, just having virsh console for compat. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: virt-console
On Tue, Jul 01, 2008 at 08:02:03PM +0100, Daniel P. Berrange wrote: I hate --behave-like-you-should flags and will do everything I can to avoid them. Let's not inconvenience everybody for the sake of some possible breakage. The perils of people coding to human interfaces. (I wanted to make --verbose the default, like telnet, but that seemed much more likely to break someone's scripts). I'm mostly concerned about 'virsh console' - we only need to keep compatability for that. The standalone virt-console can have the auto-track restarts syntax and we can recommend use for virt-console as the primary tool, just having virsh console for compat. Hmm, I'm not sure that's much of an improvement. Currently virsh is a great one-stop shop for managing instances, it would be a shame if we had to break that. Fundamentally I don't believe that virsh console was ever a stable interface to program to. Given that it goes to the domain console, how could it be? The output of the domain on the console is surely not stable. (In Solaris land, we deal with this by explicitly documenting stability of output and such; it's very much a shame that the wider UNIX community never picked up on this.) regards john -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] incorrect VIR_DOMAIN_NONE usage
As I was trying to understand exact semantics of the libvirt flags api,
I found an error in the xs_internal.c file.
When it wants to indicate that it cannot report the state of the domain,
it user VIR_DOMAIN_NONE as a return value, which does not, in fact,
refer to a domain state at all, but is a dummy flag for creating
domains, instead of VIR_DOMAIN_NOSTATE.
This patch does not affect the compiled code, only the readability.
On a related note, the defined enum flags seem inconstent to me, half of
them have explicitly named 0 default values, and half of them don't,
it's a bit confusing.
If
enum virStorageVolDeleteFlags {
VIR_STORAGE_VOL_DELETE_NORMAL= 0: Delete metadata only (fast)
VIR_STORAGE_VOL_DELETE_ZEROED= 1: Clear all data to zeros (slow)
}
then why not
enum virConnectFlags {
VIR_CONNECT_RW=0: A read-write connection
VIR_CONNECT_RO= 1: A readonly connection
}
?
It would not affect existing code, and would make the library more
consistent.
regards
István
? .project
? xs_internal_constant_semantics.patch
Index: src/xs_internal.c
===
RCS file: /data/cvs/libvirt/src/xs_internal.c,v
retrieving revision 1.65
diff -u -p -r1.65 xs_internal.c
--- src/xs_internal.c 10 Apr 2008 16:54:54 - 1.65
+++ src/xs_internal.c 1 Jul 2008 19:46:41 -
@@ -399,7 +399,7 @@ xenStoreGetDomainInfo(virDomainPtr domai
info-state = VIR_DOMAIN_RUNNING;
free(tmp);
} else {
-info-state = VIR_DOMAIN_NONE;
+info-state = VIR_DOMAIN_NOSTATE;
}
tmp = virDomainDoStoreQuery(domain-conn, domain-id, memory/target);
if (tmp != NULL) {
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirt on mingw: undefined reference to htonl/ntohl
Hi, Brecht One additional Note for libvirt python dll file python25.dll is not correctly working as we expected. We should try Python-MinGW. http://python-mingw.donbennett.org/mywiki/HomePage DLL should export _imp__* funtions. But We cannot see it on Python Windows Installation package. I have no time to check into this issue. Thanks Atsushi SAKAI Brecht Sanders [EMAIL PROTECTED] wrote: Hi, On my end I also had built libvirtmod.a, but without a DLL version of this file I don't think it will be loadable as a Python module. Or is there a way to load or link static libraries somehow in Python? Brecht P.S.: I didn't understand your spelling remark. Atsushi SAKAI wrote: Hi, Brecht I can compile and generate .a file on python directory. Sorry for spelling (I am using Zen-kaku(2byte) character in your name.) Thanks Atsushi SAKAI Atsushi SAKAI [EMAIL PROTECTED] wrote: Hi, Breｃｈｔ I can make .a file(not .dll). With following instruction. ==1== Install http://www.python.org/ftp/python/2.5.2/python-2.5.2.msi to /usr/local/(C:\msys\1.0\local) and copy to include file to /usr/include/python2.5 and copy /usr/local/python.exe pythonw.exe to /usr/local/bin ==2== Install to /usr/local (C:\msys\1.0\local) http://ftp.gnome.org/pub/GNOME/binaries/win32/pygobject/2.14/pygobject-2.14.1-1.win32-py2.5.exe make and make install seems work fine. Thanks Atsushi SAKAI Atsushi SAKAI [EMAIL PROTECTED] wrote: Hi, Brecht Just out of curiosity, have you done anything with virsh or the DLL you have built? Yes By the way, I am doing to build Python bingings on MinGW. But it will need to do tomorrow, since many compilation warnings. Thanks Atsushi SAKAI Brecht Sanders [EMAIL PROTECTED] wrote: Hi, I guesss I had got as far as you did. To Install Python on Windows you will need to download and install the following: http://www.python.org/ftp/python/2.5.2/python-2.5.2.msi http://ftp.gnome.org/pub/GNOME/binaries/win32/pygobject/2.14/pygobject-2.14.1-1.win32-py2.5.exe http://ftp.gnome.org/pub/GNOME/binaries/win32/pycairo/1.4/pycairo-1.4.12-1.win32-py2.5.exe http://ftp.gnome.org/pub/GNOME/binaries/win32/pygtk/2.12/pygtk-2.12.1-2.win32-py2.5.exe Also, don't forget to set some environment variables: export PYDIR=/C/Prog/Python25 export PYTHONHOME=$PYDIR export PYTHONPATH=$PYDIR/Lib/site-packages export PATH=$MINGWPREFIX:$MINGWPREFIX/bin:$PATH Just out of curiosity, have you done anything with virsh or the DLL you have built? Regards, Brecht Atsushi SAKAI wrote: Hi, Bericht By your suggestion, I am recognizing python bindings are not created(on my configuration). If you notice me to install python on MinGW, I will try to investigate it. My posting mail is follows(it does not create python library) https://www.redhat.com/archives/libvir-list/2008-June/msg00201.html It creates general library and virsh only. Thanks Atsushi SAKAI Brecht Sanders [EMAIL PROTECTED] wrote: No. Can you tell me where to find it? I also noticed that I only produced one DLL: libvirt-0.dll. No Python module DLL was built. Were you able to build this? Atsushi SAKAI wrote: Hi, Did you check my instruction for libvirt on MinGW? Thanks Atsushi SAKAI Brecht Sanders [EMAIL PROTECTED] wrote: Hi, Some time passed by and I thought I'd have another go at compiling libvirt for win32 using MinGW/MSYS again. I tried to compile libvirt-0.4.3 and I got around most obstacles. Now it just seems I am stuck when it is trying to link. My search on google showed me that I am not the first one to see this issue. Usually i means -lws2_32 is in the wrong place. However I tried moving it around without luck. Also it doesn't make sense to me that only htonl and ntohl are missing. It appears anything else used from the winsock library is found during linking. I feel we're very close to getting libvirt compiled on win32. Or do you know if anyone already succeeded? Regards Brecht Sanders gcc -shared .libs/libvirt_la-libvirt.o .libs/libvirt_la-memory.o .libs/libvirt_la-hash.o .libs/libvirt_la-test.o .libs/libvirt_la-buf.o .libs/libvirt_la-qparams.o .libs/libvirt_la-capabilities.o .libs/libvirt_la-xml.o .libs/libvirt_la-event.o .libs/libvirt_la-xen_unified.o .libs/libvirt_la-xen_internal.o .libs/libvirt_la-xs_internal.o .libs/libvirt_la-xend_internal.o .libs/libvirt_la-stats_linux.o .libs/libvirt_la-sexpr.o .libs/libvirt_la-virterror.o .libs/libvirt_la-proxy_internal.o .libs/libvirt_la-conf.o .libs/libvirt_la-xm_internal.o .libs/libvirt_la-remote_internal.o .libs/libvirt_la-bridge.o .libs/libvirt_la-iptables.o
