lkml.org 
[lkml]   [2009]   [Dec]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/23/2009 09:27 PM, Andi Kleen wrote:
> Ingo Molnar<mingo@elte.hu> writes:
>
>
>> Yes, there's (obviously) compatibility requirements and artifacts and past
>> mistakes (as with any software interface), but you need to admit it to
>>
> Yes that's exactly what I meant.
>

And we do make plenty of mistakes. And when we fix them, we have to
maintain bug-compatibility to allow live migration from the broken
version to the good version. If you're ever feeling overly happy, do
some compat work in qemu and it will suck a year's worth or two of your
life force a pop.

>> yourself that your "virtualization is sloppy just like hardware" claim is just
>>
> In my experience hardware is a lot less sloppy than software.
> Imagine your latest CPU had as many regressions as 2.6.32 @)
>
> I wish software and even VMs were as good.
>
>

Me too.

>> a cheap excuse to not do a proper job of interface engineering.
>>
> Past mistakes cannot be easily fixed. And undoubtedly even the new
> shiny interfaces will have bugs and problems. Also the behaviour is
> often not completely understood. Maybe it can be easier debugged with
> fully available source, but even then it's hard to fix the old
> software (or rather even if you can fix it deploy the fixes). In
> that regard it's a lot like hardware.
>
> I agree with you that this makes it important to design good
> interfaces, but again realistically mistakes will be made
> and they cannot be all fixed retroactively.
>

Our principal tool for this is to avoid introducing new interfaces
whenever possible. We try to stick to established hardware standards
(so we don't need to sloppily define them, and get guest compatibility
for free).

Hardware (both virt and non-virt) faces the same problems as software
here. So as hardware solutions are introduced, we adopt them, and
usually the virt extensions vendors follow with accelerations for these
paths as well.

--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.



\
 
 \ /
  Last update: 2009-12-23 21:29    [W:0.162 / U:0.728 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site