![]() | |||||||||||||
Messages in this thread |
On Fri, 04 Aug 2006 17:04:59 +1000 Rusty Russell <rusty@rustcorp.com.au> wrote: > On Thu, 2006-08-03 at 22:53 -0700, Andrew Morton wrote: > > On Fri, 04 Aug 2006 15:04:35 +1000> > Rusty Russell <rusty@rustcorp.com.au> wrote: > > > > > On Thu, 2006-08-03 at 21:18 -0700, Andrew Morton wrote: > > > Everywhere in the kernel where we have multiple implementations we want > > > to select at runtime, we use an ops struct. Why should the choice of > > > Xen/VMI/native/other be any different? > > > > 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. > VMI was proposed as the appropriate way to > connect Linux to Xen, *and* native, *and* VMWare's hypervisors (and > others). This way one Linux binary can boot on all three, using > different VMI blobs. That also is correct. > > > 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. > 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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2006-08-04 09:25 [from the cache] ©2003-2008 | |||||||||||||