Re: Xen & VMI?

[Ingo Molnar]

* Chris Wright <chrisw@xxxxxxxxxxxx> wrote:

> > i'm still arguing the same: that doing the same thing via 
> > overlapping, conflicting, redundant ABIs is crazy and contrary to 
> > the basic interests of Linux. It's like having 5 different, parallel 
> > variants of sys_open(), interfaced via a convoluted open_ops.
> 
> I would've said 5 parallel implementations of inode->i_op simply given 
> the nature of the operations, which is entirely sane.

with the big freaking difference that the 5 parallel implementations of 
inode->i_op are:

	_internal to Linux_

Doh. There's only a data ABI underneath them.

every time someone tried to impose a functional/behavioral ABI on core 
bits of Linux we said: 'no way dude!'. Remember STREAMS? Remember the 
module KABI? Remember ACPI? [doh, i guess we messed up on the latter 
one. We regret that day ever since.]

(network file systems are a bit of an exception to the rule, but those 
are pretty isolated themselves and in no way as wide and central as the 
direction paravirt_ops appears to grow.)

> > having data ABI coupling is one thing (filesystems, network formats, 
> > etc.). But having a 5-way function ABI coupling between system 
> > software running on the /same piece of hardware/, doing the same 
> > thing in essence is just madness in my book.
> 
> This is where I'm not understanding your argument.  The hardware is 
> somewhat irrelevant since the OS is running on a platform presented by 
> the hypervisor.  And the point is to allow multiple implementations of 
> the OS opertations that interact with the platform.  And in essence 
> all network stacks and file systems are doing the same thing with the 
> same hardware. [...]

again, those are /DATA/ ABIs. Not function ABIs. Not behavioral ABIs. 
The coupling is /FAR/ saner and far more plannable and far more 
isolated. And even data ABIs are very non-trivial ...

	Ingo
-
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/