Ingo Molnar wrote:
> yep. That's precisely my worry. And it doesnt have to be a 'great' thing
> - just any random small change in the kernel that makes sense: what is
> the likelyhood that it cannot be implemented, no matter what amount of
> insight, paravirt_ops + hyper-ABI emulation hackery, for FoobieVisor,
> because FoobieVisor messed up its ABI.
>
> that likelyhood is a pure function of how FoobieVisor's hypercall ABI is
> shaped. Wow! So can you guess where my fixation about not having too
> many ABIs could possibly originate from? ;-)
>
OK, so its a problem that's happened before. "It's a great idea, it's
so nice, but it breaks X." Your options are:
1. Well, nobody is really using X. We can stop supporting it.
2. X makes up 50% of the users, we'll just have to do without your
great idea.
3. Maybe we can get X updated so this idea works.
If X is a piece of hardware, then you're probably stuck with options 1
and 2. If its something like firmware or a hypervisor, you might have a
chance with option 3.
The hypervisor interface is not at all special in this regard; you may
as well be arguing "We can't allow a port of Linux to the FoobieTron2000
CPU, because it might constrain some future development"; that's true,
it might. But I don't think I've ever seen anyone make that argument
for not accepting a new architecture port.
I don't really understand what your overall argument is though. Sure, I
guess its that if there's one ABI for all hypervisors, then you've only
got one hypervisor-related constraint to consider when evaluating a new
kernel change. But that ABI is going to be as constraining as the its
most constraining hypervisor, so you're not really in a better position
than if you have N hypervisor ABIs. In fact you're worse off, because
you have no flexibility to drop/adapt/whatever the real blocker.
> _Now_ at least i've got this minimal
> admission that FoobieVisor _might_ break. Quite a breakthrough =B-)
If you went to all that typing to get that much of a concession, then
you have way too much time ;)
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
