This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: A proposal - binary

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

<Prev in Thread] Current Thread [Next in Thread>