Re: hardwired VMI crap

[Zachary Amsden]

Ingo Molnar wrote:
> * Zachary Amsden <zach@xxxxxxxxxx> wrote:
>
>   
> > [...]  So it is a little late to tell us - "redesign your hypervisor, 
> > or else.."
> >     
>
> is this how long the "paravirt_ops hides all the details and the VMI 
> hypervisor ABI will never hinder Linux" sham lasted? Now that your stuff 
> is upstream barely 2 weeks you say that it needs a redesign of your 
> hypervisor to implement our suggestions? And your argument is: "oops, 
> we've got product plans, too late for that, sorry"?
>   

Clever way to misconstrue my point.  If I took the same tack with your 
espousal of hypervisor API philosophy and cited all the different 
opinions you've been spewing lately, I think we could probably make a 
strong argument that VMI should be the model used by all hypervisors and 
should support any frankenstein combination of virtual and traditional 
hardware, because it should work for all types of emulated silicon.

We don't need to redesign our hypervisor, but that is what a lot of 
people seem to want us to do.  And there is no reason nor is there time 
to do it.

> _we_ have to live with that mess for years, and part of our job is to 
> say 'NO' when we see mess coming up. And no, it's not our job to solve 
> it for you.

You don't   have to live with any mess.  If you change the kernel 
interfaces to clockevents to pass around XML based time encodings, or 
you completely rewrite the way APIC and IO-APIC interact with the 
interrupt subsystem, and this breaks our code, there is a shared 
responsibility to make things work, but we are actively maintaining the 
code and will continue to do so.  If at some point we don't, the code 
gets marked broken, and eventually deprecated.  And there is no mess for 
you to live with.

We just want a way to work with the in-kernel interfaces that is blessed 
and correct, and that is where you could give feedback, but instead you 
refuse to delve into technical details of our proposed solutions, while 
blasting and breaking all of our current code.   We're trying to do the 
right thing and get feedback and design this thing right with the 
community, and all you can offer is violence and non-productive 
criticism - "nack, this is crap" is not a good answer.

So we'll just randomly try all of the proposed solutions until we find 
one that isn't nacked, which is a waste of everybody's time, but 
hopefully finds the correct solution.  Or you could just look at the 
solutions I proposed and tell me which ones you think are best.

Zach
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/