linux-kernel - Re: Xen & VMI?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070306210334.GC26348@elte.hu>
Date:	Tue, 6 Mar 2007 22:03:34 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Chris Wright <chrisw@...s-sol.org>
Cc:	Gerd Hoffmann <kraxel@...e.de>,
	virtualization <virtualization@...ts.osdl.org>,
	Jan Beulich <jbeulich@...ell.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Roland McGrath <roland@...hat.com>
Subject: Re: Xen & VMI?


* Chris Wright <chrisw@...s-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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/