[Libvir] [Patch] Compilation cleanup
Hi, This patch fixes following message in compilation. === xm_internal.h:64: warning: 'xenXMDomainAttachDevice' declared 'static' but never defined xm_internal.h:65: warning: 'xenXMDomainDetachDevice' declared 'static' but never defined === Signed-off-by: Atsushi SAKAI <[EMAIL PROTECTED]> Thanks Atsushi SAKAI fix_libvirt_xm_compile.patch Description: Binary data -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [PATCH] for MinGW Re: [Libvir] Pthreads error in windows compilation
Hi, Rich I just took pthread.h from pthread-win32. http://sourceware.org/pthreads-win32/ I think it is correct way. Or any other way exists? Thanks Atsushi SAKAI "Richard W.M. Jones" <[EMAIL PROTECTED]> wrote: > Atsushi SAKAI wrote: > > Hi, > > > > Today I recognized. > > It would be better to write #include in hash.h than hash.c. > > And compilation works if configure.in changes in MINGW? > > Would you apply this patch? > > I think actually it's better to push the '#include ' all the > way up into src/internal.h. It's required in other places, eg. in > src/libvirt.c. > > However, the biggest problem I have is I don't have pthread.h in MinGW. > Where do you get pthread from for MinGW? > > About the other part of this patch: > > -MINGW_EXTRA_LDFLAGS="-no-undefined" > +MINGW_EXTRA_LDFLAGS="-lintl -lpthreadGC2" > > '-no-undefined' is required in order to get libtool to build a DLL. > > Rich. > > -- > Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ > Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod > Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in > England and Wales under Company Registration No. 03798903 > -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [PATCH] Fix the function that remove the element of the hash table.
The reappearance procedures: #1 The logic error that use released memory area. 1. define two or more domains which are same hash key. (ex. the domain names are "domain_01" and "domain_28") 2. execute virsh by interactive mode 3. execute "list --all" command. 4. undefine a domain on another session. (ex. undefine domain_28) 5. execute "list --all" command. Segmentation Fault occur. #2 The logic error that doesn't remove elements. 1. define two or more domains which are same hash key. 2. execute virsh by interactive mode 3. execute "list --all" command. 4. undefine the defined domains on another session. 5. execute "list --all" command. A domain is not removed from the list during the fixed time(10sec). On 2008/02/06 17:38, Jim Meyering wrote: Hiroyuki Kaguchi <[EMAIL PROTECTED]> wrote: Though this patch has not been applied yet, are there any problems in this patch? If there is no problem, could you apply this patch ? (2008/01/29 23:45), Daniel P. Berrange wrote: On Tue, Jan 29, 2008 at 11:32:04AM +0900, Hiroyuki Kaguchi wrote: There are two logic error and a unnecessary else-statement in virHashRemoveSet function. This patch fix the following. (1/3) The logic error that use released memory area. (2/3) The logic error that doesn't remove elements. Considering your analysis, I'm sure there's no problem. However, it would be far easier to accept if we could easily demonstrate the failures. Can you provide a stand-alone test case that provokes #1 and #2? Ideally, it would be in the form of a main program that initializes a hash table, performs some inserts and then performs the offending deletion. Bonus points if you also add a test case (run by "make check") that fails before your patch and passes once it's applied. (3/3) Unnecessary else-statement. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] [patch 2/2] Dont crash if theres no /sys/hypervisor/capabilities
xenHypervisorMakeCapabilitiesXML() can be called with either
of it's FILE* paramaters NULL; don't crash when the capabilities
pointer is NULL.
Signed-off-by: Mark McLoughlin <[EMAIL PROTECTED]>
Index: libvirt/src/xen_internal.c
===
--- libvirt.orig/src/xen_internal.c 2008-02-06 22:38:06.0 +
+++ libvirt/src/xen_internal.c 2008-02-06 23:38:54.0 +
@@ -2233,7 +2233,7 @@
*/
/* Expecting one line in this file - ignore any more. */
-if (fgets (line, sizeof line, capabilities)) {
+if (capabilities && fgets (line, sizeof line, capabilities)) {
/* Split the line into tokens. strtok_r is OK here because we "own"
* this buffer. Parse out the features from each token.
*/
--
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] [patch 0/2] Fix two misc patches
Hi, Ignore this mail and look at the two following ... I can't figure out how to make "quilt mail" send one of these intro mails, even when sending a single patch :-) Cheers, Mark. -- -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] [patch 1/2] Create directory for saving iptables rules
The patch which reworked the iptables rules saving
accidently dropped the call to virFileMakePath()
resulting in:
Failed to saves iptables rules to
/var/lib/libvirt/iptables/filter/INPUT.chain : No such file or directory
Re-instate the virFileMakePath() call.
Signed-off-by: Mark McLoughlin <[EMAIL PROTECTED]>
Index: libvirt/src/iptables.c
===
--- libvirt.orig/src/iptables.c 2008-02-06 23:14:28.0 +
+++ libvirt/src/iptables.c 2008-02-06 23:15:33.0 +
@@ -238,6 +238,12 @@
#ifdef ENABLE_IPTABLES_LOKKIT
int err;
+if ((err = virFileMakePath(rules->dir))) {
+qemudLog(QEMUD_WARN "Failed to create directory %s : %s",
+ rules->dir, strerror(err));
+return;
+}
+
if ((err = writeRules(rules->path, rules->rules, rules->nrules))) {
qemudLog(QEMUD_WARN, "Failed to saves iptables rules to %s : %s",
rules->path, strerror(err));
--
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] [patch 3/3] Do not inline xstrtol functions
Our strtol() variants are all marked "static inline"
and with gcc 4.3 we get:
internal.h:272: error: inlining failed in call to 'xstrtol_i': call is
unlikely and code size would grow
This patch renames them to virStrToLong() and exports
them from the library as private symbols.
Alternative is to not build with -Winline.
Signed-off-by: Mark McLoughlin <[EMAIL PROTECTED]>
Index: libvirt/src/internal.h
===
--- libvirt.orig/src/internal.h
+++ libvirt/src/internal.h
@@ -261,85 +261,6 @@ int __virDomainMigratePrepare (virConnec
int __virDomainMigratePerform (virDomainPtr domain, const char *cookie, int
cookielen, const char *uri, unsigned long flags, const char *dname, unsigned
long bandwidth);
virDomainPtr __virDomainMigrateFinish (virConnectPtr dconn, const char *dname,
const char *cookie, int cookielen, const char *uri, unsigned long flags);
-/* Like strtol, but produce an "int" result, and check more carefully.
- Return 0 upon success; return -1 to indicate failure.
- When END_PTR is NULL, the byte after the final valid digit must be NUL.
- Otherwise, it's like strtol and lets the caller check any suffix for
- validity. This function is careful to return -1 when the string S
- represents a number that is not representable as an "int". */
-static inline int
-xstrtol_i(char const *s, char **end_ptr, int base, int *result)
-{
-long int val;
-char *p;
-int err;
-
-errno = 0;
-val = strtol(s, &p, base);
-err = (errno || (!end_ptr && *p) || p == s || (int) val != val);
-if (end_ptr)
-*end_ptr = p;
-if (err)
-return -1;
-*result = val;
-return 0;
-}
-
-/* Just like xstrtol_i, above, but produce an "unsigned int" value. */
-static inline int
-xstrtol_ui(char const *s, char **end_ptr, int base, unsigned int *result)
-{
-unsigned long int val;
-char *p;
-int err;
-
-errno = 0;
-val = strtoul(s, &p, base);
-err = (errno || (!end_ptr && *p) || p == s || (unsigned int) val != val);
-if (end_ptr)
-*end_ptr = p;
-if (err)
-return -1;
-*result = val;
-return 0;
-}
-
-static inline int
-xstrtol_ll(char const *s, char **end_ptr, int base, long long *result)
-{
-long long val;
-char *p;
-int err;
-
-errno = 0;
-val = strtoll(s, &p, base);
-err = (errno || (!end_ptr && *p) || p == s || (long long) val != val);
-if (end_ptr)
-*end_ptr = p;
-if (err)
-return -1;
-*result = val;
-return 0;
-}
-
-/* Just like xstrtol_i, above, but produce an "unsigned long long" value. */
-static inline int
-xstrtol_ull(char const *s, char **end_ptr, int base, unsigned long long
*result)
-{
-unsigned long long val;
-char *p;
-int err;
-
-errno = 0;
-val = strtoull(s, &p, base);
-err = (errno || (!end_ptr && *p) || p == s || (unsigned long long) val !=
val);
-if (end_ptr)
-*end_ptr = p;
-if (err)
-return -1;
-*result = val;
-return 0;
-}
#ifdef __cplusplus
}
#endif /* __cplusplus */
Index: libvirt/src/util.c
===
--- libvirt.orig/src/util.c
+++ libvirt/src/util.c
@@ -549,6 +549,87 @@ int virFileBuildPath(const char *dir,
return 0;
}
+/* Like strtol, but produce an "int" result, and check more carefully.
+ Return 0 upon success; return -1 to indicate failure.
+ When END_PTR is NULL, the byte after the final valid digit must be NUL.
+ Otherwise, it's like strtol and lets the caller check any suffix for
+ validity. This function is careful to return -1 when the string S
+ represents a number that is not representable as an "int". */
+int
+__virStrToLong_i(char const *s, char **end_ptr, int base, int *result)
+{
+long int val;
+char *p;
+int err;
+
+errno = 0;
+val = strtol(s, &p, base);
+err = (errno || (!end_ptr && *p) || p == s || (int) val != val);
+if (end_ptr)
+*end_ptr = p;
+if (err)
+return -1;
+*result = val;
+return 0;
+}
+
+/* Just like virStrToLong_i, above, but produce an "unsigned int" value. */
+int
+__virStrToLong_ui(char const *s, char **end_ptr, int base, unsigned int
*result)
+{
+unsigned long int val;
+char *p;
+int err;
+
+errno = 0;
+val = strtoul(s, &p, base);
+err = (errno || (!end_ptr && *p) || p == s || (unsigned int) val != val);
+if (end_ptr)
+*end_ptr = p;
+if (err)
+return -1;
+*result = val;
+return 0;
+}
+
+/* Just like virStrToLong_i, above, but produce an "long long" value. */
+int
+__virStrToLong_ll(char const *s, char **end_ptr, int base, long long *result)
+{
+long long val;
+char *p;
+int err;
+
+errno = 0;
+val = strtoll(s, &p, base);
+err = (errno || (!end_ptr && *p) || p == s || (long long) val != val);
+if (end_ptr)
+*end_ptr = p;
+if (er
[Libvir] [patch 2/3] Fix subscript typo when calling hypervisor domainDestroy
Fixes: xen_unified.c: In function 'xenUnifiedDomainDestroy': xen_unified.c:697: error: array subscript is above array bounds Signed-off-by: Mark McLoughlin <[EMAIL PROTECTED]> Index: libvirt/src/xen_unified.c === --- libvirt.orig/src/xen_unified.c +++ libvirt/src/xen_unified.c @@ -694,7 +694,7 @@ xenUnifiedDomainDestroy (virDomainPtr do drivers[i]->domainDestroy (dom) == 0) return 0; -if (priv->opened[i] && +if (priv->opened[XEN_UNIFIED_HYPERVISOR_OFFSET] && drivers[XEN_UNIFIED_HYPERVISOR_OFFSET]->domainDestroy && drivers[XEN_UNIFIED_HYPERVISOR_OFFSET]->domainDestroy (dom) == 0) return 0; -- -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] [patch 1/3] Move static function prototype from header
Fixes: xm_internal.h:64: error: 'xenXMDomainAttachDevice' declared 'static' but never defined xm_internal.h:65: error: 'xenXMDomainDetachDevice' declared 'static' but never defined Signed-off-by: Mark McLoughlin <[EMAIL PROTECTED]> Index: libvirt/src/xm_internal.c === --- libvirt.orig/src/xm_internal.c +++ libvirt/src/xm_internal.c @@ -77,6 +77,8 @@ static int xenXMAttachDisk(virDomainPtr xmlNodePtr node, xenXMConfCachePtr entry); static int xenXMAttachInterface(virDomainPtr domain, xmlXPathContextPtr ctxt, int hvm, xmlNodePtr node, xenXMConfCachePtr entry); +static int xenXMDomainAttachDevice(virDomainPtr domain, const char *xml); +static int xenXMDomainDetachDevice(virDomainPtr domain, const char *xml); #define XM_REFRESH_INTERVAL 10 Index: libvirt/src/xm_internal.h === --- libvirt.orig/src/xm_internal.h +++ libvirt/src/xm_internal.h @@ -61,9 +61,6 @@ int xenXMDomainUndefine(virDomainPtr dom virConfPtr xenXMParseXMLToConfig(virConnectPtr conn, const char *xml); char *xenXMDomainFormatXML(virConnectPtr conn, virConfPtr conf); -static int xenXMDomainAttachDevice(virDomainPtr domain, const char *xml); -static int xenXMDomainDetachDevice(virDomainPtr domain, const char *xml); - #ifdef __cplusplus } #endif -- -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] [patch 0/3] Fix some gcc 4.3.0 warnings
Hi, With gcc-4.3.0 (from Fedora rawhide), some new warnings are thrown up. The following three patches fixes them. The first two are straightforward, I think, but perhaps people might prefer to remove -Winline from our warning flags rather than apply the last patch. Cheers, Mark. -- -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] python/libvir.c returning wrong value on error?
Daniel P. Berrange wrote:
> On Wed, Feb 06, 2008 at 03:18:13PM -0500, Cole Robinson wrote:
>> Hi all,
>>
>> Looking at python/libvir.c, all the custom functions return VIR_PY_NONE
>> on error. This unfortunately doesn't map well to some of the
>> generated python bindings which expect an error val of -1. So if these
>> commands fail, no exception will be thrown at the python level.
>> (Ex. virDomainGetAutostart, virDomainGetVcpus and their python equiv.)
>>
>> I'm wondering where the fix should be: in python/libvir.c, changing
>> these error return values, or in the generator somewhere?
>
> The fix should be in the libvir.c file - I didn't write this custom
> bindings correctly. Simply remove the line
>
> if (c_retval < 0)
> return VIR_PY_NONE;
>
> So 'c_retval' will get propagated back to the pure python layer which
> will do the -1 check
>
> Regards,
> Dan.
Hmm, I don't think any of the cases where there is an error actually
end up returning c_retval, its always python wrapped contents of
something passed by reference, so I don't know how that would work.
The patch below seems to do the job: I tested it with the autostart
function on a xen domain (which errors as its not supported) and it
now correctly throws an exception from the python bindings.
Thanks,
Cole
diff --git a/python/libvir.c b/python/libvir.c
index 96555b3..67d6252 100644
--- a/python/libvir.c
+++ b/python/libvir.c
@@ -27,6 +27,8 @@ extern void initcygvirtmod(void);
is so common that we encapsulate it here. Now, each use is simply
return VIR_PY_NONE; */
#define VIR_PY_NONE (Py_INCREF (Py_None), Py_None)
+#define VIR_PY_INT_FAIL (libvirt_intWrap(-1))
+#define VIR_PY_INT_SUCCESS (libvirt_intWrap(0))
/
* *
@@ -214,15 +216,15 @@ libvirt_virDomainSetSchedulerParameters(PyObject *self
ATTRIBUTE_UNUSED,
c_retval = virDomainGetSchedulerType(domain, &nparams);
if (c_retval == NULL)
-return VIR_PY_NONE;
+return VIR_PY_INT_FAIL;
free(c_retval);
if ((params = malloc(sizeof(*params)*nparams)) == NULL)
-return VIR_PY_NONE;
+return VIR_PY_INT_FAIL;
if (virDomainGetSchedulerParameters(domain, params, &nparams) < 0) {
free(params);
-return VIR_PY_NONE;
+return VIR_PY_INT_FAIL;
}
/* convert to a Python tupple of long objects */
@@ -269,17 +271,17 @@ libvirt_virDomainSetSchedulerParameters(PyObject *self
ATTRIBUTE_UNUSED,
default:
free(params);
-return VIR_PY_NONE;
+return VIR_PY_INT_FAIL;
}
}
if (virDomainSetSchedulerParameters(domain, params, nparams) < 0) {
free(params);
-return VIR_PY_NONE;
+return VIR_PY_INT_FAIL;
}
free(params);
-return VIR_PY_NONE;
+return VIR_PY_INT_SUCCESS;
}
static PyObject *
@@ -383,11 +385,11 @@ libvirt_virDomainPinVcpu(PyObject *self ATTRIBUTE_UNUSED,
domain = (virDomainPtr) PyvirDomain_Get(pyobj_domain);
if (virNodeGetInfo(virDomainGetConnect(domain), &nodeinfo) != 0)
-return VIR_PY_NONE;
+return VIR_PY_INT_FAIL;
cpumaplen = VIR_CPU_MAPLEN(VIR_NODEINFO_MAXCPUS(nodeinfo));
if ((cpumap = malloc(cpumaplen)) == NULL)
-return VIR_PY_NONE;
+return VIR_PY_INT_FAIL;
memset(cpumap, 0, cpumaplen);
truth = PyBool_FromLong(1);
@@ -403,7 +405,7 @@ libvirt_virDomainPinVcpu(PyObject *self ATTRIBUTE_UNUSED,
Py_DECREF(truth);
free(cpumap);
-return VIR_PY_NONE;
+return VIR_PY_INT_SUCCESS;
}
@@ -1030,7 +1032,7 @@ libvirt_virDomainGetAutostart(PyObject *self
ATTRIBUTE_UNUSED, PyObject *args) {
LIBVIRT_END_ALLOW_THREADS;
if (c_retval < 0)
-return VIR_PY_NONE;
+return VIR_PY_INT_FAIL;
py_retval = libvirt_intWrap(autostart);
return(py_retval);
}
@@ -1053,7 +1055,7 @@ libvirt_virNetworkGetAutostart(PyObject *self
ATTRIBUTE_UNUSED, PyObject *args)
LIBVIRT_END_ALLOW_THREADS;
if (c_retval < 0)
-return VIR_PY_NONE;
+return VIR_PY_INT_FAIL;
py_retval = libvirt_intWrap(autostart);
return(py_retval);
}
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] python/libvir.c returning wrong value on error?
On Wed, Feb 06, 2008 at 03:18:13PM -0500, Cole Robinson wrote: > Hi all, > > Looking at python/libvir.c, all the custom functions return VIR_PY_NONE > on error. This unfortunately doesn't map well to some of the > generated python bindings which expect an error val of -1. So if these > commands fail, no exception will be thrown at the python level. > (Ex. virDomainGetAutostart, virDomainGetVcpus and their python equiv.) > > I'm wondering where the fix should be: in python/libvir.c, changing > these error return values, or in the generator somewhere? The fix should be in the libvir.c file - I didn't write this custom bindings correctly. Simply remove the line if (c_retval < 0) return VIR_PY_NONE; So 'c_retval' will get propagated back to the pure python layer which will do the -1 check Regards, 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 -=| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] python/libvir.c returning wrong value on error?
Hi all, Looking at python/libvir.c, all the custom functions return VIR_PY_NONE on error. This unfortunately doesn't map well to some of the generated python bindings which expect an error val of -1. So if these commands fail, no exception will be thrown at the python level. (Ex. virDomainGetAutostart, virDomainGetVcpus and their python equiv.) I'm wondering where the fix should be: in python/libvir.c, changing these error return values, or in the generator somewhere? Thanks, Cole -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] Re: libvirt for Python on Windows
Aha, the big question.
So far I only have loose notes, but basically it comes down to the
instructions below.
I used SWIG (http://www.swig.org/) to build the DLL of the Python module.
My setup had Python 2.4 installed in C:\Prog\Python24. Of course the
required C dependancies where also already met on my system (including
libxen).
I have quite some experience in porting *nix stuff to Windows/win32
using MinGW/MSYS, but Python was new to me.
Nevertheless it took my days (well, nights mostly) to get this result,
but the instructions below aren't too long. So I believe it shouldn't
require that many changes to sources and autoconf/automake stuff to
incorporate the MinGW/MSYS port.
I'm afraid there is still some work ahead meeting all the Python
dependancies. If we're lucky they will exist for Windows. Otherwise they
will need porting too (hopefully easier than libvirt).
Here goes:
wget -c http://downloads.sourceforge.net/swig/swigwin-1.3.33.zip
unzip -oqj swigwin-1.3.33.zip -d /C/Prog/Python24 swigwin-1.3.33/swig.exe
wget -c http://libvirt.org/sources/libvirt-cvs-snapshot.tar.gz
tar xfz libvirt-cvs-snapshot.tar.gz
cd libvirt-0.4.0
mkdir linux
touch linux/param.h
mv src/internal.h src/internal.h.bak
echo "#include " > src/internal.h
sed -e 's/^\(#define VIR_DEBUG(.*) *\)$/\1 \\/' src/internal.h.bak >>
src/internal.h
mv qemud/remote_protocol.c qemud/remote_protocol.c.bak
echo "#include " > qemud/remote_protocol.c
cat qemud/remote_protocol.c.bak >> qemud/remote_protocol.c
mv configure configure.bak
sed -e "s?/include/python\${PYTHON_VERSION}?/include?;
s?/lib/python\${PYTHON_VERSION}/site-packages?$/Lib/site-packages?;
s?-lpython\\\${PYTHON_VERSION}?-lpython\`echo \\\$PYTHON_VERSION|sed -e
's/\\\.//'\`?" configure.bak > configure
./configure --prefix=$INSTALLPREFIX --disable-rpath --enable-debug=no
--enable-compile-warnings=minimum --with-xen --without-xen-proxy
--without-qemu --without-openvz --without-test --without-libvirtd
--without-remote --with-init-scripts=none --with-depends --without-sasl
--without-polkit --with-python=/C/Prog/Python24/python.exe
PYTHON=/C/Prog/Python24/python.exe
PYTHON_INCLUDES="/C/Prog/Python24/include" CFLAGS="-Drestrict=__restrict
-DWSAAPI=" LDFLAGS="-no-undefined -lportablexdr -lwsock32 -lintl"
# don't build tests
mv tests/Makefile tests/Makefile.bak
cat > tests/Makefile << EOF
all:
install:
EOF
make install
cd python
mv Makefile Makefile.bak
sed -e "s?^\(PYTHON_INCLUDES *= *.*\)?\1/C/Prog/Python24/include?;
s?^\(PYTHON_SITE_PACKAGES *=
*.*\)?\1/C/Prog/Python24/Lib/site-packages?" Makefile.bak > Makefile
/C/Prog/Python24/python.exe generator.py
make libvirtmod_la-libvir.lo libvirtmod_la-types.lo
libvirtmod_la-libvirt-py.lo
# use SWIG to create Python wrapper
cat > libvirtmod.i << EOF
%module libvirtmod
%{
#include "../include/libvirt/libvirt.h"
%}
EOF
sed -e "s/^\(.*libvirt.*\)$/extern \1/" libvirt-py.h >> libvirtmod.i
../../swigwin-1.3.33/swig -python -I../../swigwin-1.3.33/Lib
-I../../swigwin-1.3.33/Lib/python/ libvirtmod.i
gcc -shared libvirtmod_wrap.c libvirtmod_la-libvir.o
libvirtmod_la-types.o libvirtmod_la-libvirt-py.o -lportablexdr -lws2_32
-I/C/Prog/Python24/include -L/C/Prog/Python24/libs -lpython24
-L../src/.libs/ -lvirt -Wl,--export-all-symbols -o _libvirtmod.dll
# test it
/C/Prog/Python24/python.exe -c "import libvirt"
cp libvirt.py libvirtmod.py _libvirtmod.dll
/C/Prog/Python24/Lib/site-packages
Richard W.M. Jones wrote:
Brecht Sanders wrote:
Hi Richard,
I have finally compiled a libvirt Python module.
Attached are the files that need to go into home>lib/site-packages, in case you want to try this.
How did you build _libvirtmod though?
Rich.
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [PATCH] for MinGW Re: [Libvir] Pthreads error in windows compilation
On Wed, Feb 06, 2008 at 06:26:04PM +, Richard W.M. Jones wrote: > Atsushi SAKAI wrote: > >Hi, > > > >???Today I recognized. > >It would be better to write #include in hash.h than hash.c. > >And compilation works if configure.in changes in MINGW? > >Would you apply this patch? > > I think actually it's better to push the '#include ' all the > way up into src/internal.h. It's required in other places, eg. in > src/libvirt.c. Yep, I agree - internal.h is the best place. 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 -=| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [PATCH] for MinGW Re: [Libvir] Pthreads error in windows compilation
Atsushi SAKAI wrote: Hi, Today I recognized. It would be better to write #include in hash.h than hash.c. And compilation works if configure.in changes in MINGW? Would you apply this patch? I think actually it's better to push the '#include ' all the way up into src/internal.h. It's required in other places, eg. in src/libvirt.c. However, the biggest problem I have is I don't have pthread.h in MinGW. Where do you get pthread from for MinGW? About the other part of this patch: -MINGW_EXTRA_LDFLAGS="-no-undefined" +MINGW_EXTRA_LDFLAGS="-lintl -lpthreadGC2" '-no-undefined' is required in order to get libtool to build a DLL. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 smime.p7s Description: S/MIME Cryptographic Signature -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [PATCH] change a Disk/Nic of inactive domain
Daniel Veillard wrote: On Tue, Feb 05, 2008 at 04:00:14PM -0800, Ryan Scott wrote: Resurrecting a two-week old thread... Was a version of this patch ever committed? I don't see it, but I may have missed it. I used an earlier version of the patch to fix a problem we've noticed, but I would like to see the final version of the patch. Well Apparently Rich didn't commit his version. So I applied the patch made the two changes he suggested, a bit of reformating, this should now be in CVS, Thanks for doing that. As you surmised, I didn't get around to it. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 smime.p7s Description: S/MIME Cryptographic Signature -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [PATCH] change a Disk/Nic of inactive domain
On Tue, Feb 05, 2008 at 04:00:14PM -0800, Ryan Scott wrote: > > Resurrecting a two-week old thread... > > Was a version of this patch ever committed? I don't see it, but I may > have missed it. > > I used an earlier version of the patch to fix a problem we've noticed, > but I would like to see the final version of the patch. Well Apparently Rich didn't commit his version. So I applied the patch made the two changes he suggested, a bit of reformating, this should now be in CVS, thanks everybody ! Daniel > S.Sakamoto wrote: > These struct definitions *intentionally* private. > >>>Oops, I did not notice it... > >>> > >>>I revised a patch not to access the struct data directly. > >>In principle this patch looks good. If no one else objects, I'll commit > >>this, with a few of my own fixes (below). > >> > >>Rich. > >> > >>+(obj->stringval) && !strcmp((char*)obj->stringval, "hvm")) > >> > >>I'm going to use STREQ macro here instead of !strcmp. > >> > >>+if (ctxt) > >>+xmlXPathFreeContext(ctxt); > >> > >>There are a few potential double-frees on the cleanup path. Need to set > >>ctxt back to NULL after freeing it. > >> > >Thank you for improving my patch! > >Because it looks like that no one else objects, please commit this. > > > >Thanks, > >Shigeki Sakamoto. > > > >-- > >Libvir-list mailing list > >Libvir-list@redhat.com > >https://www.redhat.com/mailman/listinfo/libvir-list > > -- > Libvir-list mailing list > Libvir-list@redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list -- 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: [Libvir] don't use virBufferAdd with string literals
On Tue, Feb 05, 2008 at 04:02:32PM +, Daniel P. Berrange wrote: > On Mon, Feb 04, 2008 at 08:27:41PM +0100, Jim Meyering wrote: > > I noticed a little glitch here: > > > > src/xml.c: virBufferAdd(buf, "(usbdevice tablet)", 13); > > src/xml.c: virBufferAdd(buf, "(usbdevice tablet)", 18); > > > > So I mounted a campaign to remove all such uses of virBufferAdd > > and make sure no more sneak back in. > > First, I added this definition: > > > > #define virBufferAddLit(buf_, literal_string_) \ > > virBufferAdd (buf_, "" literal_string_ "", sizeof literal_string_ - 1) > > > > The empty double quotes ensure that you get a syntax error if you > > pass anything other than a string literal in the 2nd parameter. > > > > The idea being to change, e.g., the above examples to this: > > > > virBufferAddLit(buf, "(usbdevice tablet)"); > > > > FYI, I converted almost all of the uses of virBufferAdd like this: > > This is great - every single place where virBufferAdd is used without > a 3rd param of '-'1 is a bug waiting to strike. So how about we now Hum, that could be used in a very valid way for example to add only the prefix of a string or if you know you have a non 0 terminated string. 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
[Libvir] Re: libvirt for Python on Windows
Brecht Sanders wrote: Hi Richard, I have finally compiled a libvirt Python module. Attached are the files that need to go into home>lib/site-packages, in case you want to try this. How did you build _libvirtmod though? Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 smime.p7s Description: S/MIME Cryptographic Signature -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] Re: [PATCH] add missing qemudReportError
On Wed, Feb 06, 2008 at 03:23:50PM +0100, Guido Guenther wrote:
> I just noticed that the patch got mangled, sorry:
> On Tue, Feb 05, 2008 at 01:09:15PM +0100, Guido Guenther wrote:
> > That said it might also be worthwhile to not let libvirtd segfault
> > because of a missing call to qemudReportError - this is debatable
> > though:
>
> diff --git a/src/qemu_conf.c b/src/qemu_conf.c
> index 6e4f39c..e382afa 100644
> --- a/src/qemu_conf.c
> +++ b/src/qemu_conf.c
> @@ -2524,7 +2524,7 @@ qemudLoadConfig(struct qemud_driver *driver,
> if (!(def = qemudParseVMDef(NULL, driver, xml, file))) {
> virErrorPtr err = virGetLastError();
> qemudLog(QEMUD_WARN, "Error parsing QEMU guest config '%s' : %s",
> - path, err->message);
> + path, err ? err->message : "BUG: unknown error - please
> report\n");
> return NULL;
> }
Okay, I have applied both patches, which just a bit of reformating,
thanks !
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: [Libvir] Re: libvirt on mingw
Richard W.M. Jones wrote: Brecht Sanders wrote: Hello again, Note that I am using gcc (mingw) 3.4.5, and not 4 as you recommend. The attached patch got rid of the warnings though. Maybe there is a compiler switch to fix it in a cleaner way though. Anyway, with the attached patch it does compile. Basically it casts to void* before converting to a different type. Regards Yes thanks, that patch does indeed fix it. I'll apply it and release a new version shortly. OK, PortableXDR version 4.0.8 contains your fix + I also fixed the Makefile so it actually builds a DLL again under MinGW: http://et.redhat.com/~rjones/portablexdr/ Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 smime.p7s Description: S/MIME Cryptographic Signature -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] Re: libvirt on mingw
Brecht Sanders wrote: Hello again, Note that I am using gcc (mingw) 3.4.5, and not 4 as you recommend. The attached patch got rid of the warnings though. Maybe there is a compiler switch to fix it in a cleaner way though. Anyway, with the attached patch it does compile. Basically it casts to void* before converting to a different type. Regards Yes thanks, that patch does indeed fix it. I'll apply it and release a new version shortly. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 smime.p7s Description: S/MIME Cryptographic Signature -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] Re: [PATCH] add missing qemudReportError
I just noticed that the patch got mangled, sorry:
On Tue, Feb 05, 2008 at 01:09:15PM +0100, Guido Guenther wrote:
> That said it might also be worthwhile to not let libvirtd segfault
> because of a missing call to qemudReportError - this is debatable
> though:
diff --git a/src/qemu_conf.c b/src/qemu_conf.c
index 6e4f39c..e382afa 100644
--- a/src/qemu_conf.c
+++ b/src/qemu_conf.c
@@ -2524,7 +2524,7 @@ qemudLoadConfig(struct qemud_driver *driver,
if (!(def = qemudParseVMDef(NULL, driver, xml, file))) {
virErrorPtr err = virGetLastError();
qemudLog(QEMUD_WARN, "Error parsing QEMU guest config '%s' : %s",
- path, err->message);
+ path, err ? err->message : "BUG: unknown error - please
report\n");
return NULL;
}
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[PATCH] for MinGW Re: [Libvir] Pthreads error in windows compilation
Hi, Today I recognized. It would be better to write #include in hash.h than hash.c. And compilation works if configure.in changes in MINGW? Would you apply this patch? Anyway virsh.exe works fine, but cannot compile testutils.c. Thanks Atsushi SAKAI "Richard W.M. Jones" <[EMAIL PROTECTED]> wrote: > Gabriel Kaufmann wrote: > > In order to fix this problem, I installed the ‘pthreads’ package on my > > MinGW. > > > > Then added include pthread.h in src/internal.h > > Is this the right action? > > Yes, I think so. This sounds like a regression. > > Rich. > > -- > Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ > Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod > Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in > England and Wales under Company Registration No. 03798903 > mingw_pthread_compilation.patch Description: Binary data mingw_compilation_configurein.patch Description: Binary data -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [PATCH] Fix the function that remove the element of the hash table.
Hiroyuki Kaguchi <[EMAIL PROTECTED]> wrote: > Though this patch has not been applied yet, are there any problems in this > patch? > If there is no problem, could you apply this patch ? > > (2008/01/29 23:45), Daniel P. Berrange wrote: >> On Tue, Jan 29, 2008 at 11:32:04AM +0900, Hiroyuki Kaguchi wrote: >>> There are two logic error and a unnecessary else-statement >>> in virHashRemoveSet function. >>> >>> This patch fix the following. >>> (1/3) The logic error that use released memory area. >>> (2/3) The logic error that doesn't remove elements. Considering your analysis, I'm sure there's no problem. However, it would be far easier to accept if we could easily demonstrate the failures. Can you provide a stand-alone test case that provokes #1 and #2? Ideally, it would be in the form of a main program that initializes a hash table, performs some inserts and then performs the offending deletion. Bonus points if you also add a test case (run by "make check") that fails before your patch and passes once it's applied. >>> (3/3) Unnecessary else-statement. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [PATCH] Fix the function that remove the element of the hash table.
Though this patch has not been applied yet, are there any problems in this
patch?
If there is no problem, could you apply this patch ?
(2008/01/29 23:45), Daniel P. Berrange wrote:
On Tue, Jan 29, 2008 at 11:32:04AM +0900, Hiroyuki Kaguchi wrote:
There are two logic error and a unnecessary else-statement
in virHashRemoveSet function.
This patch fix the following.
(1/3) The logic error that use released memory area.
(2/3) The logic error that doesn't remove elements.
(3/3) Unnecessary else-statement.
Index: hash.c
===
RCS file: /data/cvs/libvirt/src/hash.c,v
retrieving revision 1.27
diff -u -r1.27 hash.c
--- hash.c 21 Jan 2008 16:29:10 - 1.27
+++ hash.c 28 Jan 2008 06:48:09 -
@@ -543,6 +543,7 @@
if (prev) {
prev->next = entry->next;
free(entry);
+entry = prev;
} else {
if (entry->next == NULL) {
entry->valid = 0;
ACK, this is definitely needed.
@@ -553,6 +554,7 @@
sizeof(virHashEntry));
free(entry);
entry = NULL;
+i--;
}
}
table->nbElems--;
I'm still not 100% clear on the logic around here, but I
think your suggestion is correct.
@@ -560,8 +562,6 @@
prev = entry;
if (entry) {
entry = entry->next;
-} else {
-entry = NULL;
}
}
}
ACK, clearly correct.
Dan.
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
