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

quoted

* Jeremy Fitzhardinge (jeremy@goop.org) wrote:
  

quoted

Chris Wright wrote:
    

quoted

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.

quoted

quoted

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.

quoted

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.

quoted

  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