On Mon, Jan 14, 2008 at 01:51:56PM +, Daniel P. Berrange wrote:
On Mon, Jan 14, 2008 at 12:25:44PM +, Richard W.M. Jones wrote:
S.Sakamoto wrote:
These struct definitions *intentionally* private.
Oops, I did not notice it...
I revised a patch not to access the struct data
On Wed, Jan 16, 2008 at 09:56:16AM +, Richard W.M. Jones wrote:
Daniel P. Berrange wrote:
How about this patch. I define VIR_DEBUG in src/internal.c. Each module
which wants to output debug messages adds
#define DEBUG(fmt,...) VIR_DEBUG(driver, fmt, __VA_ARGS__)
#define DEBUG0(msg)
On Tue, Jan 15, 2008 at 01:07:17AM +, Daniel P. Berrange wrote:
Whenever we change any of the embedded API docs or add new APIs we end up
with huge diffs on the docs/APIchunk*.html files. These HTML files don't
seem to be visible anywhere on the website, nor are there even any a href
links
Another thing is that there's confusion over where 'flags' parameters
should be unsigned or not. The confusion comes from existing calls
which are a bit of a hodge-podge, even using 'long' in one case:
virConnectOpenAuth int flags
virDomainCreateLinux unsigned int flags
This function confuses me a bit. It takes a virStoragePoolPtr as
parameter, but it only uses pool-conn. The other two
virStorageVolLookupBy* functions take a virConnectPtr directly.
virStorageVolPtr
virStorageVolLookupByName(virStoragePoolPtr pool,
const char *name)
Daniel P. Berrange wrote:
On Fri, Jan 18, 2008 at 07:55:35PM +, Daniel P. Berrange wrote:
On Fri, Jan 18, 2008 at 07:44:41PM +, Richard W.M. Jones wrote:
A few comments:
You should put #include config.h at the very top of all your C files
(before any other headers/defines), to avoid
On Sat, Jan 19, 2008 at 01:47:30PM +, Richard W.M. Jones wrote:
This function confuses me a bit. It takes a virStoragePoolPtr as
parameter, but it only uses pool-conn. The other two
virStorageVolLookupBy* functions take a virConnectPtr directly.
There are 3 levels of unique identifiers
On Sat, Jan 19, 2008 at 01:19:35PM +, Richard W.M. Jones wrote:
Another thing is that there's confusion over where 'flags' parameters
should be unsigned or not. The confusion comes from existing calls
which are a bit of a hodge-podge, even using 'long' in one case:
virConnectOpenAuth
Daniel P. Berrange [EMAIL PROTECTED] wrote:
...
Since you're working on the weekend ;-), here are some
notices I'd begun to accumulate:
There are a bunch of new uses of open64, which isn't portable.
How about using AC_SYS_LARGEFILE in configure.in instead?
Then you can use open everywhere.
On Sat, Jan 19, 2008 at 07:09:31PM +0100, Jim Meyering wrote:
Daniel P. Berrange [EMAIL PROTECTED] wrote:
...
Since you're working on the weekend ;-), here are some
notices I'd begun to accumulate:
There are a bunch of new uses of open64, which isn't portable.
How about using
Currently, if the app provides NULL as the connect URI, we always connect
to a Xen hypervisor.
virsh provides a VIR_DEFAULT_CONNECT_URI env var which can be used to
override this. virt-install/virt-manager never use NULL, and now try
to 'guess' a default URI based on whether /dev/kvm or
Xen 3.2.0 removed the sockets_per_node field from the nodeinfo data returned
by XenD. I previously add compat for this, but got it in the wrong place
so it would most likely end up in a divide-by-zero error. This patch
re-arranges it to be correct.
diff -rup
On Sat, Jan 19, 2008 at 05:11:26AM -0500, Daniel Veillard wrote:
On Wed, Jan 16, 2008 at 09:56:16AM +, Richard W.M. Jones wrote:
Daniel P. Berrange wrote:
How about this patch. I define VIR_DEBUG in src/internal.c. Each module
which wants to output debug messages adds
#define
Daniel P. Berrange [EMAIL PROTECTED] wrote:
On Sat, Jan 19, 2008 at 07:09:31PM +0100, Jim Meyering wrote:
...
In storage_backend_loop.c, it looks like vol-target.path can be leaked.
Which function is that in ? Since originally writing it I've changed all
error path cleanup code to simply
The openvz_driver.c file registers an implementation of the networking
driver APIs, which is a no-op.
Even though the networking APIs are implemented in the QEMU driver, this
one impl is *shared* and used across all virtualization driver backends.
Thus no other driver such as Xen/OpenVZ/etc
Jim's xstrtol convenience function simplified the use of strtol, but only
support the 'int' variant. For the storage drivers I need a similar function
that will always be at minimum 64-bit since we may have files 2 GB even
on 32-bit. So this adds a variant of the xstrtol functions which use a
The referencing counting code for Connect/Domain/Network objects has many
repeated codepaths, not all of which are correct. eg, the virFreeDomain
method forgets to release networks when garbage collecting a virConnectPtr,
and the virFreeNetwork method forgets to release domains. I've also found
Daniel P. Berrange [EMAIL PROTECTED] wrote:
Jim's xstrtol convenience function simplified the use of strtol, but only
support the 'int' variant. For the storage drivers I need a similar function
that will always be at minimum 64-bit since we may have files 2 GB even
on 32-bit. So this adds a
Daniel P. Berrange [EMAIL PROTECTED] wrote:
Actually that's OK - the contract of the 'volCreate' method in the backend
does not require free'ing of the 'vol' object upon failure. Becaue 'vol'
is passed in pre-allocated, it is the caller's responsibilty to release
the 'vol' object upon failure.
On Sat, Jan 19, 2008 at 08:28:38PM +0100, Jim Meyering wrote:
Daniel P. Berrange [EMAIL PROTECTED] wrote:
Jim's xstrtol convenience function simplified the use of strtol, but only
support the 'int' variant. For the storage drivers I need a similar function
that will always be at minimum
This patch makes virsh use the virFileReadAll API from util.c, instead of
duplicating it. This means we need to export this symbol from the library.
diff -r 1eb02a424697 src/libvirt_sym.version
--- a/src/libvirt_sym.version Sat Jan 19 13:45:07 2008 -0500
+++ b/src/libvirt_sym.version Sat Jan
On Sat, Jan 19, 2008 at 09:21:07PM +0100, Jim Meyering wrote:
Daniel P. Berrange [EMAIL PROTECTED] wrote:
Xen 3.2.0 removed the sockets_per_node field from the nodeinfo data returned
by XenD. I previously add compat for this, but got it in the wrong place
so it would most likely end up in
Daniel P. Berrange [EMAIL PROTECTED] wrote:
Xen 3.2.0 removed the sockets_per_node field from the nodeinfo data returned
by XenD. I previously add compat for this, but got it in the wrong place
so it would most likely end up in a divide-by-zero error. This patch
re-arranges it to be correct.
On Fri, Jan 18, 2008 at 07:44:41PM +, Richard W.M. Jones wrote:
A few comments:
You should put #include config.h at the very top of all your C files
(before any other headers/defines), to avoid warnings.
I believe I've added that to all files I created now.
There was one place where
Daniel P. Berrange [EMAIL PROTECTED] wrote:
On Sat, Jan 19, 2008 at 09:21:07PM +0100, Jim Meyering wrote:
Daniel P. Berrange [EMAIL PROTECTED] wrote:
Xen 3.2.0 removed the sockets_per_node field from the nodeinfo data
returned
by XenD. I previously add compat for this, but got it in the
I was looking at xend_internal.c and wondered why sexpr_int's
sexpr pointer wasn't const... surely, it *can't* modify that, I thought.
So I made it const, and pulled the thread, which ended up making most
of the sexpr* parameters in sexpr.[ch] const.
I added the few inevitable casts, but imho,
26 matches
Mail list logo
