On Thu, Oct 09, 2008 at 02:29:18PM -0400, David Lively wrote:
> On Thu, 2008-10-09 at 18:01 +0100, Daniel P. Berrange wrote:
>
> > dump example, the time to lookup the object is likely dwarfed by the
> > time to generate the XML doc, or to talk to the QEMU monitor.
> > IMHO, optimizing this is ove
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 nutshell, it's that the current
> > impl
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 nutshell, it's that the current
> implementation of this scheme unnecessarily increases the (time)
> complexi
Hi Daniel -
I'm implementing virNodeDeviceDef, as suggested, but I just noticed
something that really bothers me. In a nutshell, it's that the current
implementation of this scheme unnecessarily increases the (time)
complexity of O(1) operations to O(n).
For example, take virDomainGetXMLDesc()
On Fri, Oct 03, 2008 at 02:35:06PM -0400, David Lively wrote:
> I definitely wasn't planning on covering all of HAL :-)
>
> I assume you weren't planning on exposing these capability-specific
> representations in the public API. Right? (If not, ignore the rest of
> this ...)
Not at this time. F
I definitely wasn't planning on covering all of HAL :-)
I assume you weren't planning on exposing these capability-specific
representations in the public API. Right? (If not, ignore the rest of
this ...)
So I guess I don't see the value of having these cap-specific internal
representations. I
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.
>
> I'm really trying to avoid creating a struct/union that must be extended
> every time we support a new capability. I struggled qu
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 Fri, Oct 03, 2008 at 09:57:43AM -0400, David Lively wrote:
> 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 patc
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..9a94f6d 100644
> --- a/src/internal.h
> +++ b/src/internal.h
> @@ -292,6 +307,25 @@ struct _virStorageVol {
> };
>
>
> +/**
> + * _virNodeDevice:
> + *
> + * Internal s
On Fri, Oct 03, 2008 at 11:02:55AM -0400, David Lively wrote:
> 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
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 licensing problem that HA
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
On Tue, Sep 30, 2008 at 12:17:27AM -0400, David Lively wrote:
> Hi Daniel -
>
> I'm not really ready to submit this yet (hence no [PATCH] in the
> subject), but it is functional enough to play with, mostly with the
> HAL-based driver, though the devkit-based one works too. In particular,
> I'm
On Tue, Sep 30, 2008 at 12:17:27AM -0400, David Lively wrote:
> Hi Daniel -
>
> I'm not really ready to submit this yet (hence no [PATCH] in the
> subject), but it is functional enough to play with, mostly with the
> HAL-based driver, though the devkit-based one works too. In particular,
> I'm
Hi Daniel -
I have an implementation underway right now, with both HAL- and
Devkit-based "drivers". We have some folks who need this *next week*,
so I'm trying to get the most functionality finished up today and this
weekend.
The generic (HAL/Devkit-agnostic) framework is essentially done and
On Thu, Aug 21, 2008 at 03:18:57PM -0400, David Lively wrote:
> 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
On Fri, Aug 22, 2008 at 09:44:47AM +0100, Daniel P. Berrange wrote:
> On Thu, Aug 21, 2008 at 03:18:57PM -0400, David Lively wrote:
> > 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.
On Thu, Aug 21, 2008 at 03:18:57PM -0400, David Lively wrote:
> 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
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
20 matches
Mail list logo
