[added Ingo since he'd probably be interested in this] On Fri, 2007-03-16 at 21:00 -0700, Jeremy Fitzhardinge wrote: > Chris Wright wrote: > > * Jeremy Fitzhardinge (jeremy@xxxxxxxx) wrote: > > > >> Chris Wright wrote: > >> > >>> Consistently wrap paravirt ops callsites > >>> "ugh" - mingo > >>> > >> Had a thought. What if we do a kind of reverse/two-way module linkage? > >> Somehow compile each pv-op implementation like a module, and then link > >> the appropriate one in at boot time. > >> > > > > This is very similar to something Steve was chatting with me about > > this morning. The idea he was tossing around was something a bit like > > an initrd that a load_module analog could link up. In a sense, it's > > similar to the VMI ROM, with the exceptions that the ABI is just created > > by the compiler from a normal mutable kernel API and it's linkage with > > symbols available on both sides. > > > > Yeah. It would have to happen a lot earlier than initrd. It would be > more like a multiboot kernel module or something. I was taking a look at kernel/module.c and arch/i386/kernel/module.c and it looks like we can copy/modify the former and use part of the later. > > >> Tricky parts: it would need two-way unresolved references between kernel > >> and module, and it would need to be able to run very early in the > >> kernel's life. > >> > > > > This is the tricky part, and where Steve and I left off. > > > I think it's possible. It still be tricky. We need to handle percpu variables. But I have some ideas on how to do it though. > Fortunately the linker code should be pretty easy to make > self-contained. It shouldn't need to do memory allocations or anything > complex like that, so I think its just a matter of grovelling around and > fixing up linkages. Well, we still need to make sure the kernel knows about this image, so that it doesn't write over it. I guess that can be done like the initrd is. > > > I suspect we could free the unused backends already. > > We could; we just need to make sure they get their own section so > they're easily separable. > > > It also has one > > negative side-effect, which is promoting external module code that links > > with the kernel. IOW, there's much less incentive to get code merged > > if it's just a matter of linking. > > It wouldn't be something we'd promote by making it easy to bind > out-of-tree code to the interface. And it would still be a > kernel-version-specific ABI; no guarantees of stability. It will be very similar to how we handle modules (and out of tree modules). -- Steve _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
