On Tue, Sep 09, 2008 at 05:25:09PM +0300, Avi Kivity wrote:
> Glauber Costa wrote:
>> Hey guys,
>>
>> Some eons before the dinosaurs went extinct, we used to support
>> a method of memory allocation different than the one advertised by
>> KVM_CAP_USER_MEMORY.
>>
>> This series of patches attempt on removing the support for it in 
>> kvm-userspace
>> entirely. It will make the job of integrating kvm and qemu much easier. As
>> a matter of fact, platforms other than x86 (and ia64, because it seems to
>> borrow a great deal of code from x86) don't even support that method. 
>>
>> I remind you that for those who still want to run userspaces old enough for 
>> Hypervisors
>> that lack user memory capability, you always have the option of running an
>> old enough userspace, so to match. 
>>
>> This patch series leaves one test for this capability in place, at machine
>> initialization: KVM will refuse to run if it's not in there. Later on,
>> if we deprecate the capability altogether from the kernel, we may do it 
>> through
>> an ABI check. But for now, I think this is enough.
>>
>> series stat:
>>   
>
> Looks good.  Two comments that are simultaneously critical and minor:
>
> - use git send-email -n to number patches so I they are lexically sorted  
> for git am (oh and --no-chain-reply-to also helps)
gee. I use this regularly, but this time I forgot ;-(
Sorry master.

> - qemu code is formatted with 4-space indents, no tabs.  your patches  
> seem to have 4-position tabs (which could only have been created by the  
> recently-opened LHC, as they don't occur naturally).  please talk to  
> your editor.
Part of them. Of course one of them might have been a screw up, but mostly,
I'm using 4 spaces for code under qemu/, and tabs for code in libkvm, which 
seems
to be the standard. Should I use spaces for libkvm too?

>
> -- 
> error compiling committee.c: too many arguments to function
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to