Re: Xen & VMI?

Ingo Molnar
2007-03-06T21:04:05Z

* Chris Wright <chrisw@sous-sol.org> 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