On Fri, 2007-03-16 at 10:24 +0100, Ingo Molnar wrote: > * Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote: > > > Wrap a set of interesting paravirt_ops calls in a wrapper which makes > > the callsites available for patching. Unfortunately this is pretty > > ugly because there's no way to get gcc to generate a function call, > > but also wrap just the callsite itself with the necessary labels. > > > > This patch supports functions with 0-4 arguments, and either void or > > returning a value. 64-bit arguments must be split into a pair of > > 32-bit arguments (lower word first). Small structures are returned in > > registers. > > ugh. This is beyond ugly! Why dont we just compile two images, one for > Xen and one for native, do two passes to get those two images and > 'merge' them into a single vmlinuz (so that we still have a 'single' > kernel unit to deal with on the distro side). This way we avoid all this > crazy, limited, fragile patchery business...
But with lguest, VMI and kvm I don't think that's a good idea. For background: the current patching code is ugly too, but it only deals with the 6 most common functions, so it's contained. This gets us pretty close to !CONFIG_PARAVIRT performance. (But slowdown is still measurable). We get worse with Xen wanting to alter mkpte et al. By the time we patch another 6 functions (each one slightly different), we get pretty close to general coverage anyway, so it's clearer to do them all. I think the question is, can we do it better than this? My previous attempts (which lead to the current code) ranged from ugly to very ugly 8( Rusty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
