so the Domain's Connect would wrap the clone). I
don't think this does much in the remote case (since the underlying RPC
pipe it still shared, albeit safely). But I suppose it might allow
greater concurrency in the non-remote cases. Is this what you had in
mind?
Dave
On Wed, 2008-12-17 at
On Wed, 2008-12-17 at 13:58 +, Daniel P. Berrange wrote:
> On Wed, Dec 17, 2008 at 07:44:15AM -0500, David Lively wrote:
> > Hi Daniel -
> > When I apply these patches, I'm seeing segfaults on event delivery
> > when just running the existing synchronous
> >
tinue looking into it. But please let me know if you're
familiar with the problem ...
Thanks,
Dave
On Tue, 2008-12-16 at 10:24 -0500, David Lively wrote:
> Hi Daniels -
> Sorry for the delay. Life's been crazy. But now I'm finally looking
> into using this series of patches
gt; On Tue, Nov 18, 2008 at 01:12:42PM -0500, David Lively wrote:
> > On Tue, 2008-11-18 at 16:51 +, Daniel P. Berrange wrote:
> > > On Tue, Nov 18, 2008 at 11:06:10AM -0500, David Lively wrote:
> > > > The attached patch (against libvirt-java) implements Java bindings fo
On Sat, 2008-11-22 at 08:21 +0100, Jim Meyering wrote:
> David Lively <[EMAIL PROTECTED]> wrote:
> > On Fri, 2008-11-21 at 17:51 +0100, Jim Meyering wrote:
> > I'm printing the (user-supplied) object names to help in debugging
> > misbehaving python EventImp
On Mon, 2008-11-24 at 17:30 +0100, Jim Meyering wrote:
> David Lively <[EMAIL PROTECTED]> wrote:
> > On Sat, 2008-11-22 at 08:21 +0100, Jim Meyering wrote:
> >> David Lively <[EMAIL PROTECTED]> wrote:
> >> > On Fri, 2008-11-21 at 17:51 +0100, Jim Mey
On Fri, 2008-11-21 at 14:49 +0100, Daniel Veillard wrote:
> On Wed, Nov 19, 2008 at 11:22:31AM -0500, David Lively wrote:
> > On Wed, 2008-11-19 at 10:35 -0500, David Lively wrote:
> > > The patch already synchronizes operations using virConnect objects with
> > > e
On Fri, 2008-11-21 at 17:51 +0100, Jim Meyering wrote:
> No big deal, but there are several debug printf uses here that look
> like they try to print NULL pointers upon memory allocation failure.
> It's ok with glibc's printf of course, but not for others.
You're right. Attached patch fixes those
Okay, *this* one seems to be a complete fix.
Dave
tests/Makefile.am | 29 ++---
1 file changed, 22 insertions(+), 7 deletions(-)
On Fri, 2008-11-21 at 12:35 -0500, David Lively wrote:
> Hold off on considering this quite yet. I don't think it's a c
Hold off on considering this quite yet. I don't think it's a complete
fix. I'll followup with a complete one soon.
Dave
On Fri, 2008-11-21 at 11:04 -0500, David Lively wrote:
> The last change to tests/Makefile.am broke the build when --without-xen
> is specified.
The last change to tests/Makefile.am broke the build when --without-xen
is specified. This patch fixes it ...
Dave
tests/Makefile.am |9 +
1 file changed, 9 insertions(+)
diff --git a/tests/Makefile.am b/tests/Makefile.am
index d2d1254..cc159e0 100644
--- a/tests/Makefile.am
+++
Doh! ... attached :-)
On Fri, 2008-11-21 at 10:30 +0100, Jim Meyering wrote:
> David Lively <[EMAIL PROTECTED]> wrote:
> > This patch gets python events working again after upstream changes, and
> > make the test implementation properly clean up after itself and
> >
This patch gets python events working again after upstream changes, and
make the test implementation properly clean up after itself and
implement the new EventImpl API properly.
Note that the Python RemoveHandle and RemoveTimeout implementations
should return the opaque object registered by the co
register
for domain events (w/VIR_ERR_NO_SUPPORT rather than blissfully continue
when we can't possibly deliver events).
Dave
remote_internal.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
commit 02239f3e0fedf1c3860826f13efe356223b38e3c
Author: David Lively &l
crash.
Dave
domain_event.c | 38 ++
domain_event.h |3 +++
qemu_driver.c |5 -
3 files changed, 45 insertions(+), 1 deletion(-)
commit d70494a2c2ebdf985943020cc84f22713904719a
Author: David Lively <[EMAIL PROTECTED]>
Date: Thu Nov 20 16
On Wed, 2008-11-19 at 18:33 +, Daniel P. Berrange wrote:
> On Wed, Nov 19, 2008 at 01:28:23PM -0500, David Lively wrote:
> > On Wed, 2008-11-19 at 16:49 +, Daniel P. Berrange wrote:
> > > On Wed, Nov 19, 2008 at 11:41:43AM -0500, David Lively wrote:
> > > >
On Wed, 2008-11-19 at 16:49 +, Daniel P. Berrange wrote:
> On Wed, Nov 19, 2008 at 11:41:43AM -0500, David Lively wrote:
> > While starting to think about Windows compability, I realized the newly
> > exposed API for registering an external EventImpl is not adequate.
>
While starting to think about Windows compability, I realized the newly
exposed API for registering an external EventImpl is not adequate.
Currently it's assuming 32-bit unix fds. But Windows uses a pointer
(HANDLE) here. So we need to generalize this interface so it can be
implemented for 64-bit
On Wed, 2008-11-19 at 10:35 -0500, David Lively wrote:
> The patch already synchronizes operations using virConnect objects with
> each other. To avoid making illegal EventImpl callbacks from Java for
> the current libvirt, I have to lock every Connect object known to Java
> and hold
On Wed, 2008-11-19 at 10:48 +, Daniel P. Berrange wrote:
> On Wed, Nov 19, 2008 at 08:34:41AM +0100, Daniel Veillard wrote:
> > On Tue, Nov 18, 2008 at 01:12:42PM -0500, David Lively wrote:
> > > On Tue, 2008-11-18 at 16:51 +, Daniel P. Berrange wrote:
> > > >
On Mon, 2008-11-17 at 22:22 +, Daniel P. Berrange wrote:
> On Mon, Nov 17, 2008 at 03:55:13PM -0500, David Lively wrote:
> Functionally this all looks fine.
>
> From a style point of view, we should keep consistency with the other
> virEventAddHandle func in terms of typing /
On Tue, 2008-11-18 at 16:51 +, Daniel P. Berrange wrote:
> On Tue, Nov 18, 2008 at 11:06:10AM -0500, David Lively wrote:
> > The attached patch (against libvirt-java) implements Java bindings for
> > libvirt domain events. This version provides a libvirt EventImpl
> > ru
On Tue, 2008-11-18 at 17:05 +, Daniel P. Berrange wrote:
> On Tue, Nov 18, 2008 at 11:18:38AM -0500, David Lively wrote:
> > This patch allows the remote driver to work with an asynchronous
> > EventImpl (it's the only one using an externally-supplied one), assuming
>
This patch allows the remote driver to work with an asynchronous
EventImpl (it's the only one using an externally-supplied one), assuming
libvirt is compiled with pthread support. (Without pthreads, this code
is harmless in a single-threaded environment.)
Basically it uses a mutex to protect read
On Fri, 2008-11-14 at 12:59 -0500, David Lively wrote:
> On Fri, 2008-11-14 at 17:09 +, Daniel P. Berrange wrote:
> > Or have the virConnectDomainEventRegister method take an extra parameter
> > which is a callbackvoid (*freefunc)(void*). libvirt would just invoke
>
On Fri, 2008-11-14 at 13:41 +, Mark McLoughlin wrote:
> The DeviceKit implementation seems to be much more of a work-in-progress
> than the HAL implementation - maybe disable it by default in configure?
> (i.e. with_devkit=no instead of with_devkit=check)
That's a good idea. I don't think the
On Fri, 2008-11-14 at 13:28 +, Daniel P. Berrange wrote:
> On Fri, Nov 14, 2008 at 12:46:09PM +, Mark McLoughlin wrote:
> >
> > On Thu, 2008-11-13 at 17:30 +, Daniel P. Berrange wrote:
> > > This patch is the public API parts of the node device enumeration code.
> > > No changes since
On Fri, 2008-11-14 at 13:20 +, Mark McLoughlin wrote:
> On Thu, 2008-11-13 at 17:31 +, Daniel P. Berrange wrote:
> >
> > +virBufferVSprintf(&buf, " \n",
> > + virNodeDevCapTypeToString(caps->type));
> > +switch (caps->type) {
> ...
> > +case
On Fri, 2008-11-14 at 17:09 +, Daniel P. Berrange wrote:
> On Fri, Nov 14, 2008 at 12:00:10PM -0500, David Lively wrote:
> >
> > > > +JNIEXPORT void JNICALL Java_org_libvirt_Connect_registerForDomainEvents
> > > > +(JNIEnv *env, jobject obj, jlong VCP){
On Wed, 2008-11-12 at 10:22 +0100, Daniel Veillard wrote:
> On Fri, Nov 07, 2008 at 03:46:37PM -0500, David Lively wrote:
> > It shouldn't be hard to make this thread-safe using Java synchronized
> > methods and statements, but I haven't done that yet. Should I??
On Fri, 2008-11-14 at 14:11 +, Daniel P. Berrange wrote:
> On Fri, Nov 14, 2008 at 07:36:27AM -0500, Ben Guthro wrote:
> > I'll answer for Dave, while I'm looking at this.
> >
> > As far as I know, Dave is of the opinion that we are just "getting lucky"
> > using the APIs as we are, and remai
The attached patch (against libvirt-java) contains Java bindings for the
new domain event code. It works (see EventTest.java), but there's a
certain amount of hokiness regarding the EventImpl stuff that I'd like
to discuss.
Unlike the C and Python interfaces, the Java interface does not
currently
P.S. Patch 7/7 (Java bindings for host dev enum) hasn't changed.
On Thu, 2008-11-06 at 21:32 -0500, David Lively wrote:
> Daniel(s) -
> In the attached set of patches, I've merged in DanB's reworking of the
> headers, etc. and adjusted my code accordingly. I've a
ocs here ...]
On Wed, 2008-11-05 at 16:49 +, Daniel P. Berrange wrote:
> On Wed, Nov 05, 2008 at 11:26:07AM -0500, David Lively wrote:
> > On Wed, 2008-11-05 at 11:51 +, Daniel P. Berrange wrote:
> I think the problem here is that the existing Avahi mdns code in the
> libv
On Wed, 2008-11-05 at 11:51 +, Daniel P. Berrange wrote:
> DevKit & HAL are just APIs built ontop of DBus, so the key here
> is integration with DBus watch APIs. AFAIK, those only require
> that the event loop impl have one callback per unique FD.
Here's what I'm seeing when registering for d
Hi Folks -
Since virEventRegisterImpl is now public (in libvirt.h), a nagging
concern of mine has become more urgent. Essentially this callback gives
clients a way of registering their own "handle (fd) watcher" and "timer"
functionality for use by libvirt.
What bugs me is the inconsistency be
On Tue, 2008-10-28 at 14:13 +0100, Daniel Veillard wrote:
> On Tue, Oct 21, 2008 at 01:54:13PM -0400, David Lively wrote:
> > This patch contains the internal API additions.
>
> Looks fine to me, just a couple of questions:
>
> > +// TODO: Implement PCI bus d
t's clear that we're monitoring the node's devices (and not
virtual ones).
Dave
On Tue, 2008-10-28 at 14:01 +0100, Daniel Veillard wrote:
> On Tue, Oct 21, 2008 at 01:49:19PM -0400, David Lively wrote:
> > This patch contains the public API additions.
> >
>
>
This patch (for libvirt-java) contains Java bindings for node device
enumeration.
diff --git a/src/Makefile.am b/src/Makefile.am
index 5200c1d..466a0eb 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -14,6 +14,7 @@ java_libvirt_source_files = \
org/libvirt/Error.java \
org/libvirt/Netw
This patch contains python bindings for node device enumeration.
diff --git a/python/generator.py b/python/generator.py
index ca83eaf..108dfc2 100755
--- a/python/generator.py
+++ b/python/generator.py
@@ -258,6 +258,11 @@ py_types = {
'const virConnectPtr': ('O', "virConnect", "virConnectPt
This patch contains virsh support for node device enumeration.
diff --git a/src/virsh.c b/src/virsh.c
index 89aa4fa..67963f0 100644
--- a/src/virsh.c
+++ b/src/virsh.c
@@ -4415,6 +4415,83 @@ cmdVersion(vshControl *ctl, const vshCmd *cmd ATTRIBUTE_UNUSED)
}
/*
+ * "node-list-devices" command
+
This patch contains the remote implementation of node device
enumeration.
diff --git a/qemud/remote.c b/qemud/remote.c
index a623494..56d88a7 100644
--- a/qemud/remote.c
+++ b/qemud/remote.c
@@ -66,6 +66,7 @@ static void make_nonnull_domain (remote_nonnull_domain *dom_dst, virDomainPtr do
static
This patch contains the HAL-based implementation, and a preliminary
DeviceKit-based implementation, of node device enumeration. The Devkit
impl is very incomplete, mostly because Devkit itself is very immature
at this stage.
diff --git a/configure.in b/configure.in
index 2d7fb14..3486a47 100644
-
This patch contains additions to the internal API for host device
enumeration.
diff --git a/src/hash.c b/src/hash.c
index 0a5bdcd..424c4a7 100644
--- a/src/hash.c
+++ b/src/hash.c
@@ -687,6 +687,9 @@ virGetConnect(void) {
ret->storageVols = virHashCreate(20);
if (ret->storageVols == NULL
This patch contains the public API changes for host device enumeration.
diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
index 97aea7d..0b0a4bc 100644
--- a/include/libvirt/libvirt.h.in
+++ b/include/libvirt/libvirt.h.in
@@ -995,6 +995,74 @@ virDomainPtrvirDomain
Since the version of this I posted last week still had some outstaning
TODO items that I have since finished, I'm re-submitting the whole
thing. I consider this a "complete submission" since I don't think it's
necessary to implement any additional functionality to make this
acceptable. (The two r
This patch (for libvirt-java) implements Java bindings for the node
device enumeration functions.
Dave
diff --git a/src/Makefile.am b/src/Makefile.am
index 5200c1d..466a0eb 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -14,6 +14,7 @@ java_libvirt_source_files = \
org/libvirt/Error.java
Currently __virStringListFree is freeing only the list nodes, but not
the strings on the list (and neither is anyone else freeing these).
This small patch fixes that, and documents the two __virStringList
functions.
Dave
diff --git a/src/libvirt.c b/src/libvirt.c
index 8fd594b..bee98d2 100644
---
This tiny patch adds $LIBVIRT_CFLAGS to the flags used when compiling
the Java Native Interface C code in libvirt-java. This allows one to
build, for example, against a local (non-installed) libvirt tree.
Dave
commit dfd82305b4c871244dff2f9057e8b73a043c0213
Author: David Lively <[EM
On Thu, 2008-10-23 at 13:53 +0100, Daniel P. Berrange wrote:
> On Tue, Oct 21, 2008 at 01:45:47PM -0400, David Lively wrote:
> > * using newfangled array-based lists for NodeDeviceObj's
>
> The individual capabilities within a device are still using a linked list,
> thoug
Ok, here are proper python bindings to the node device enumeration
functions and objects.
diff --git a/python/generator.py b/python/generator.py
index c706b19..0186e6e 100755
--- a/python/generator.py
+++ b/python/generator.py
@@ -258,6 +258,11 @@ py_types = {
'const virConnectPtr': ('O', "v
This patch implements the python bindings, rather lamely. I'll submit a
new version with a proper NodeDevice object soon ...
diff --git a/python/generator.py b/python/generator.py
index c706b19..a8fd969 100755
--- a/python/generator.py
+++ b/python/generator.py
@@ -258,6 +258,11 @@ py_types = {
This patch implements virsh support. It's pretty sparse right now, and
I'm not wild about the command names I chose. I welcome suggestions
(i.e., command names / args) for completing (or changing) this.
diff --git a/src/virsh.c b/src/virsh.c
index 89aa4fa..67963f0 100644
--- a/src/virsh.c
+++
This patch contains the remote impl of the node driver.
diff --git a/qemud/remote.c b/qemud/remote.c
index 72e064e..48564e6 100644
--- a/qemud/remote.c
+++ b/qemud/remote.c
@@ -66,6 +66,7 @@ static void make_nonnull_domain (remote_nonnull_domain *dom_dst, virDomainPtr do
static void make_nonnull_
This patch contains the actual HAL- and DeviceKit-based local "node"
drivers.
diff --git a/configure.in b/configure.in
index 66d271a..3441742 100644
--- a/configure.in
+++ b/configure.in
@@ -1048,6 +1048,93 @@ test "$enable_shared" = no && lt_cv_objdir=.
LV_LIBTOOL_OBJDIR=${lt_cv_objdir-.}
AC_SU
Ok, here's my substantially-reworked node device enumeration patch, this
time done with a proper understanding of the public-obj/Obj/Def
model :-) as last discussed here:
https://www.redhat.com/archives/libvir-list/2008-September/msg00398.html
I've broken it into the following pieces:
1-public-a
This patch contains the internal API additions.
diff --git a/src/hash.c b/src/hash.c
index 0a5bdcd..424c4a7 100644
--- a/src/hash.c
+++ b/src/hash.c
@@ -687,6 +687,9 @@ virGetConnect(void) {
ret->storageVols = virHashCreate(20);
if (ret->storageVols == NULL)
goto failed;
+re
This patch contains the public API additions.
diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
index 3624367..c888943 100644
--- a/include/libvirt/libvirt.h.in
+++ b/include/libvirt/libvirt.h.in
@@ -993,6 +993,76 @@ char * virStorageVolGetPath(v
On Sun, 2008-10-19 at 20:22 +0100, Daniel P. Berrange wrote:
> On Fri, Oct 17, 2008 at 11:58:15AM -0400, Ben Guthro wrote:
> > Changes to the RPC protocol
> >
> > +struct remote_domain_event_ret {
> > +remote_nonnull_domain dom;
> > +int event;
> > +unsigned long int callback;
> > +
On Thu, 2008-10-09 at 18:01 +0100, Daniel P. Berrange wrote:
> On Thu, Oct 09, 2008 at 12:25:18PM -0400, David Lively wrote:
> > Hi Daniel -
> > I'm implementing virNodeDeviceDef, as suggested, but I just noticed
> > something that really bothers me. In a nutsh
rd go to the conventional lookup impl if this
turns out to be a bad idea.)
Dave
On Fri, 2008-10-03 at 16:23 +0100, Daniel P. Berrange wrote:
> On Tue, Sep 30, 2008 at 12:17:27AM -0400, David Lively wrote:
> > diff --git a/src/internal.h b/src/internal.h
> > index d96504d..9a94
mplemented with a xmlNode representation.
On Fri, 2008-10-03 at 18:41 +0100, Daniel P. Berrange wrote:
> On Fri, Oct 03, 2008 at 01:20:35PM -0400, David Lively wrote:
> > Okay, I see what you mean. I'll create a virNodeDeviceDefPtr and follow
> > the established pattern.
> >
Okay, I see what you mean. I'll create a virNodeDeviceDefPtr and follow
the established pattern.
I'm really trying to avoid creating a struct/union that must be extended
every time we support a new capability. I struggled quite a bit with
the right representation for capabilities and bus details
On Tue, 2008-09-30 at 19:02 +0100, Daniel P. Berrange wrote:
> On Tue, Sep 30, 2008 at 12:17:27AM -0400, David Lively wrote:
> - Split stateful drivers out of libvirt.so, so they're only used
>by the daemon, and not apps linking to libvirt.so.
>
>This solves the li
On Tue, 2008-09-30 at 19:31 +0200, Daniel Veillard wrote:
> Good to see that you seems to have the python bindings ready too !
Many python bindings are not really ready (in this patch). But I should
have them in the next patch (Monday/Tuesday next week).
I have complete java bindings for the cur
otected virHashTable (like connections, domains, etc.),
so concurrent access shouldn't be a problem.
I'll post a patch (with some TODOs ...) on Sunday or Monday morning.
Dave
On Fri, 2008-09-26 at 14:15 +0100, Daniel P. Berrange wrote:
> On Thu, Aug 21, 2008 at 03:18:57PM -0400, D
Okay, at long last, I see what you mean (I think). Apps using libvirt
events must register an EventImpl via virRegisterEventImpl. Internally,
suppose we implement events via an anonymous pipe. libvirt would call
EventImpl.addHandle(pipe_read_fd, POLLIN ..., __virHandleEvents, conn)
so the a
to wrap them all for non-glib-ish implementations?
Sorry if I'm being dense. I've looked at the qemud events interface,
but I still feel like I'm missing something here.
Dave
On Mon, 2008-09-22 at 07:23 +0100, Richard W.M. Jones wrote:
> On Fri, Sep 19, 2008 at 1
On Fri, 2008-09-19 at 11:14 +0100, Richard W.M. Jones wrote:
> On Thu, Sep 18, 2008 at 12:45:07PM -0400, David Lively wrote:
> > I'm a little concerned that a vector of event type names isn't really
> > adequate for specifying a filter. Does this need to be more gener
Hi -
We have some folks looking into the implementation of events (just VM
state transition events, for now) in libvirtd. I've been assuming that
events will be XML strings, something like:
22
nostate
running
where the contents of the element are determined by the even
code consistent with the assumptions stated in
src/Makefile.am.
But note I'm assuming the assumptions in src/Makefile.am are correct.
I'm not sure what's really dependent on libvirtd, so Someone Who Knows
Better should verify this.
Thanks,
Dave
commit 24d5708877fce90c4e85e3b2ede07b74f4
On Tue, 2008-09-02 at 17:54 +0200, Jim Meyering wrote:
> Daniel Veillard <[EMAIL PROTECTED]> wrote:
> >> diff --git a/src/storage_conf.c b/src/storage_conf.c
> >> index 2f6093b..37a2040 100644
> >> --- a/src/storage_conf.c
> >> +++ b/src/storage_conf.c
> >> @@ -331,6 +331,8 @@ virStoragePoolDefPars
Thanks Daniel. I just merged in your changes. You seem to be missing a
small incremental change (checking the strdup return value for NULL),
attached.
Dave
On Tue, 2008-09-02 at 16:17 +0200, Daniel Veillard wrote:
> On Fri, Aug 29, 2008 at 03:49:27PM -0400, David Lively wrote:
> &g
On Tue, 2008-09-02 at 08:50 +0200, Jim Meyering wrote:
> There, it'd be clearer to diagnose with something like
> "missing pool source device name", since there are a few
> other "name" elements.
I see Daniel V fixed this (and other) error messages to be less
ambiguous when he committed it earlier
-define-as
I've also attached a new version of the full patch containing this
change, in case that's easier.
Thanks,
Dave
On Thu, 2008-08-21 at 20:55 +0200, Jim Meyering wrote:
> David Lively <[EMAIL PROTECTED]> wrote:
> > Oops - that was against an old base. So
On Thu, 2008-08-28 at 22:08 +0100, Daniel P. Berrange wrote:
> On Thu, Aug 28, 2008 at 05:02:29PM -0400, David Lively wrote:
> > Does "host power support" belong on the TODO?
> > (i.e. ??virConnect{Poweroff,Suspend,Hibernate,Reboot})
> >
> > ???If lib
Does "host power support" belong on the TODO?
(i.e. virConnect{Poweroff,Suspend,Hibernate,Reboot})
If libvirt is going to be the only external interface used to manage a
virtualized host, it must be able to poweroff, suspend, (hibernate?),
and reboot the host. (For hosts that support IPMI/iLO
On Wed, 2008-08-27 at 17:51 +0100, Daniel P. Berrange wrote:
> On Mon, Aug 25, 2008 at 10:33:45AM -0400, David Lively wrote:
> > After making the change I suggested above, it now feels a little strange
> > because "Pool" is gone from the name. I'm starting t
On Fri, 2008-08-22 at 16:15 +0100, Daniel P. Berrange wrote:
> On Fri, Aug 22, 2008 at 10:58:54AM -0400, David Lively wrote:
> > As long as we're on the subject of naming (and before it's too late),
> > it's been bothering me that we keep calling this "storage po
On Fri, 2008-08-22 at 19:16 +0200, Jim Meyering wrote:
> > +asprintf(&srcSpec,
> > + "",
> > + hostlen, host, port) :
>
> Do the hostname and port string need to be quoted (and/or evoke
> warning/failure), in case they contain things like "'"?
T
On Fri, 2008-08-22 at 19:16 +0200, Jim Meyering wrote:
> > +const char *name, *path;
>
> path can be const, too.
It is, at least according to my gcc (4.3.0-8, x86_64, Fedora9).
Compile the following and without FORCE_WARNING to check:
void check()
{
#ifdef FORCE_WARNING
const char *foo;
Hi Jim -
Thanks for your comments. I really appreciate the detailed look.
I'll implement your suggestions (including the refactoring of the code
to turn a virStringList into a single XML string), though I have a
question about one of them:
On Fri, 2008-08-22 at 19:16 +0200, Jim Meyering wrote:
Here's the patch with those issues addressed (also merged with latest
upstream - avoids internal.h merge conflict) ...
Dave
On Fri, 2008-08-22 at 09:50 +0100, Daniel P. Berrange wrote:
> On Thu, Aug 21, 2008 at 10:29:43AM -0400, David Lively wrote:
> > Hi Folks -
> > Here
On Fri, 2008-08-22 at 09:50 +0100, Daniel P. Berrange wrote:
> > +const char *start_tag = "\n";
> > +const char *end_tag = "\n";
>
> I'd prefer that to be- we avoid capitals in the
> XML element names everywhere else, and in the few cases of
> joining words use an underscore, but I thi
Hi -
I'm about to start working on host device enumeration, along the
(HAL-ish) lines of what was discussed back in April:
https://www.redhat.com/archives/libvir-list/2008-April/msg5.html
I know the xml details haven't been fully fleshed out, but there seems
to be agreement that it will
Hi Folks -
Here's my second pass at storage pool discovery. I've taken Daniel's
suggestion and made it return a single XML doc containing
elements rather than an array of docs (and also incorporated
suggestions from Daniel V and Jim M).
Note that the storage patch is closely related
(witho
Oops - that was against an old base. Sorry. Here's the new one.
Also fixed a few other issues ...
Dave
On Mon, 2008-08-18 at 12:12 -0400, David Lively wrote:
> Same patch, resubmitted after fixing allocation issue you pointed out.
> Looking more closely, I notice it was leakin
-12 at 05:21 -0400, Daniel Veillard wrote:
> On Fri, Aug 08, 2008 at 03:17:52PM -0400, David Lively wrote:
> > Hi Folks -
> >
> > This small patch is a proposed prerequisite for the storage pool
> > discovery patch I submitted last week.
> >
> > Daniel B
On Fri, 2008-08-15 at 10:49 +0100, Daniel Berrange wrote:
> On Fri, Aug 08, 2008 at 03:17:52PM -0400, David Lively wrote:
> > [*] Well ... almost. Note that directory pools have a similar issue --
> > the "source" of the pool is given by the -- there's no
> >
not specified. There is no requirement that pool and
source name be the same, though.
Signed-off-by: David Lively <[EMAIL PROTECTED]>
diff --git a/src/storage_backend.h b/src/storage_backend.h
index 797ca01..422f26c 100644
--- a/src/storage_backend.h
+++
tests since we haven't really
finished hashing out the API - at least some crucial XML details ...)
Dave
On Mon, 2008-08-04 at 08:25 +0200, Jim Meyering wrote:
> Hi David,
>
> I spotted a few things that would be good to change:
>
> David Lively <[EMAIL PROTECTED]&g
On Fri, 2008-08-01 at 10:40 +0100, Daniel P. Berrange wrote:
> On Wed, Jul 30, 2008 at 04:30:01PM -0400, David Lively wrote:
> > Finally, there's an underspecification issue. The XML pool
> > descriptions returned are supposed to be usable as valid input to
> > vir
Hi Folks -
I see Daniel Berrange submitted a SCSI HBA storage backend in March.
What ever happened to that? I'd be happy to pick this up if there's
more work to do (is there a code base later than the posted patch?)
In the longer run, I'm looking towards adding support necessary for FC
envir
Hi -
The attached patch implements virConnectDiscoverStoragePools mostly as
specified by Daniel Berrange in:
http://www.redhat.com/archives/libvir-list/2008-February/msg00107.html
Daniel wasn't happy with the interface for this function because it
wasn't sufficiently general, so it currently d
On Tue, 2008-07-29 at 09:44 +0100, Daniel P. Berrange wrote:
> BTW, what version of the LVM tools is SLES using - its probably useful
> to note that in the comment you added, in case the same problem is
> particular to a version, rather than just SLES
lvm2 2.02.17 (-7.19, x86_64)
But it's hard t
ding the ":?" to the regexps would do this, but this
was leaving the trailing separator in the last group match, so I ended
up tweaking the preceding group pattern as well.
Dave
commit 021470f5cfa0e770f09c73cf8a2fc270121378f6
Author: David Lively <[EMAIL PROTECTED]>
Date: Mon Jul 28 1
Currently running autogen.sh with --with-xen-distdir=something fails to
find libxenstore if there's only a 64-bit version, and subsequently
fails to enable xen support (i.e., ends up with WITH_XEN=0). This
one-line patch fixes that by telling it to search both lib and lib64.
I guess it would be b
On Thu, 2008-07-17 at 22:42 +0100, Daniel P. Berrange wrote:
> You're not missing anything - this is a TODO item. When I wrote the
> original storage APIs, I had a prototype
>
> http://www.redhat.com/archives/libvir-list/2008-February/msg00107.html
> http://www.redhat.com/archives/libvir-list/
Hi -
I'm looking into using (which I think means extending) libvirt to
enumerate "potential" storage pool resources, in particular:
* existing physical disk device names (for creating "disk" pools)
* existing logical volume group names (for creating "logical" pools)
Note that List{Defined,A
99 matches
Mail list logo
