On Fri, 2006-08-04 at 00:21 -0700, Andrew Morton wrote:
> On Fri, 04 Aug 2006 17:04:59 +1000
> Rusty Russell <rusty@xxxxxxxxxxxxxxx> wrote:
> > On Thu, 2006-08-03 at 22:53 -0700, Andrew Morton wrote:
> > > VMI is being proposed as an appropriate way to connect Linux to Xen. If
> > > that is true then no other glue is needed.
> > Sorry, this is wrong.
> It's actually 100% correct.
Err, yes. I actually misrepresented VMI: the native implementation is
inline (ie. no blob is required for native). Bad Rusty.
> > > > Yes, we could force native and Xen to work via VMI, but the result would
> > > > be less clear, less maintainable, and gratuitously different from
> > > > elsewhere in the kernel.
> > >
> > > I suspect others would disagree with that. We're at the stage of needing
> > > to see code to settle this.
> > Wrong again.
> I was referring to the VMI-for-Xen code.
I know. And I repeat, we don't have to see that part, to know that the
result is less clear, less maintainable and gratuitously different from
elsewhere in the kernel than the paravirt_ops approach. We've seen
paravirt and the VMI parts of this already.
> > We've *seen* the code for VMI, and fairly hairy.
> I probably slept through that discussion - I don't recall that things were
> that bad. Do you recall the Subject: or date?
Read the patches which Zach sent back in March, particularly:
[RFC, PATCH 3/24] i386 Vmi interface definition
[RFC, PATCH 4/24] i386 Vmi inline implementation
[RFC, PATCH 5/24] i386 Vmi code patching
If you want to hack on x86 arch code, you'd need to understand these.
Then to see the paravirt patches go to http://ozlabs.org/~rusty/paravirt
and look at the approximately-equivalent paravirt_ops patches:
There's nothing in those paravirt_ops patches which will surprise any
kernel hacker. That's my entire point: maintainable, unsurprising,
Help! Save Australia from the worst of the DMCA: http://linux.org.au/law
Xen-devel mailing list