From: Chris Wright <chrisw@sous-sol.org>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Chris Wright <chrisw@sous-sol.org>,
Virtualization Mailing List <virtualization@lists.osdl.org>
Subject: Re: todo
Date: Fri, 16 Mar 2007 20:34:52 -0700 [thread overview]
Message-ID: <20070317033452.GU10574@sequoia.sous-sol.org> (raw)
In-Reply-To: <45FB5707.3010809@goop.org>
* Jeremy Fitzhardinge (jeremy@goop.org) 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.
> 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.
> It would also limit us to plain old calls rather than
> any inlining (though that could be done separately).
>
> On the upside, it removes pv_ops, and it might simplify the question of
> how normal module exports work, since by that time they would just be
> normal kernel functions. All the calls would be normal direct calls
> rather than indirect. And it would allow us to free the memory for the
> unused pv-ops backends.
I suspect we could free the unused backends already. 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.
thanks,
-chris
next prev parent reply other threads:[~2007-03-17 3:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20070317020011.GS10574@sequoia.sous-sol.org>
2007-03-17 2:48 ` todo Jeremy Fitzhardinge
2007-03-17 3:34 ` Chris Wright [this message]
2007-03-17 4:00 ` todo Jeremy Fitzhardinge
2007-03-17 4:03 ` todo Jeremy Fitzhardinge
2007-03-17 4:55 ` todo Steven Rostedt
2008-05-20 17:44 TODO Santosh G
2008-05-26 0:58 ` TODO Randy Dunlap
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070317033452.GU10574@sequoia.sous-sol.org \
--to=chrisw@sous-sol.org \
--cc=jeremy@goop.org \
--cc=virtualization@lists.osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.