WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[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:

        008-paravirt-structure.patch
        009-binary-patch.patch

There's nothing in those paravirt_ops patches which will surprise any
kernel hacker.  That's my entire point: maintainable, unsurprising,
clear.

Rusty.
-- 
Help! Save Australia from the worst of the DMCA: http://linux.org.au/law


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

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