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.
Thanks,
Ryan
S.Sakamoto wrote:
These
I've just checked this in:
* src/xml.c (virDomainParseXMLOSDescHVM): Mark a diagnostic.
diff --git a/src/xml.c b/src/xml.c
index c3e25d5..614deb0 100644
--- a/src/xml.c
+++ b/src/xml.c
@@ -907,7 +907,7 @@ virDomainParseXMLOSDescHVM(virConnectPtr conn, xmlNodePtr
node,
bootorder[nbootorder]
"Daniel P. Berrange" <[EMAIL PROTECTED]> wrote:
> No need to wait for that. My patches don't really touch existing code
> anymore - I got the general cleanup patches all merged already - all
> the rest are basically just adding new code. So any merge conflicts
> should be fairly minimal / easy to r
On Mon, Feb 04, 2008 at 06:04:32PM +0100, Jim Meyering wrote:
> Any objection to a mass removal of trailing blanks?
>
> [ If you haven't yet been adversely affected by e.g., pointless conflicts
> due solely to differences in white space, count yourself lucky, and
> chalk it up to not having to
Roman Divacky wrote:
hi
I am messing with libvirt and I need to add some methods to the
xenUnifiedDriver structure. I do it this way:
(currently #ifdef-ed out)
struct xenUnifiedDriver {
virDrvOpen open;
virDrvClose close;
virDrvGe
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
On Tue, Feb 05, 2008 at 01:09:15PM +0100, Guido Guenther wrote:
> On Tue, Feb 05, 2008 at 01:06:14PM +0100, Guido Guenther wrote:
> > without this qemudParseVMDef might return NULL when the boot dev
> > configuration is invalid but virGetLastError returns NULL either since
> > no error has been set
"Daniel P. Berrange" <[EMAIL PROTECTED]> wrote:
> The latest xen-unstable tree has support for booting HVM guests using an
> explicit kernel+initrd+cmdline, as an alternative to the traditional BIOS
> boot from harddisk/cdrom/network. This gives Xen HVM parity with KVM in
> terms of boot methods.
"Richard W.M. Jones" <[EMAIL PROTECTED]> wrote:
> 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);
>
> Ouch, that's a "how did that ever work".
>
> I see fr
On Tue, Feb 05, 2008 at 01:06:14PM +0100, Guido Guenther wrote:
> without this qemudParseVMDef might return NULL when the boot dev
> configuration is invalid but virGetLastError returns NULL either since
> no error has been set, this leads to a segfault in qemudLoadConfig when
> trying to print the
Hi,
without this qemudParseVMDef might return NULL when the boot dev
configuration is invalid but virGetLastError returns NULL either since
no error has been set, this leads to a segfault in qemudLoadConfig when
trying to print the error message.
Cheers,
-- Guido
diff --git a/src/qemu_conf.c b/sr
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);
Ouch, that's a "how did that ever work".
I see from that patch that you know about passing -1 as the length, in
On Tue, 2008-02-05 at 00:25 +, Daniel P. Berrange wrote:
> The main problem I know of is not VDE itself, but the means of connecting
> a VDE network to the outside world - namely the SLIRP code. Last time it
> was examined it was found to be non-64-bit clean & have significant question
> aroun
13 matches
Mail list logo
