From: Hollis Blanchard <hollis-yUx37fBWTUITNcAmw9vGhQ@public.gmane.org>
To: Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: portability layer?
Date: Wed, 28 Mar 2007 13:50:43 -0500 [thread overview]
Message-ID: <1175107843.1653.69.camel@basalt> (raw)
In-Reply-To: <460A8E44.5080305-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
On Wed, 2007-03-28 at 17:48 +0200, Avi Kivity wrote:
> Hollis Blanchard wrote:
> > On Tue, 2007-03-27 at 08:57 +0200, Avi Kivity wrote:
> >>
> >> I don't think we should be aiming at full source portability.
> >> Virtualization is inherently nonportable, and as it is mostly done in
> >> hardware, software gets to do the quirky stuff that the hardware people
> >> couldn't bother with :) instead we should be aiming at code reuse.
> >>
> >
> > I'm not sure I see the distinction you're making. Operating systems
> > could also be considered "inherently nonportable", yet Linux and the
> > BSDs support an enormous range of platforms. If you're saying that we
> > shouldn't try to run x86 MMU code on a PowerPC then I can't agree
> > more. :)
>
> No, I'm saying that some #ifdeffery in both libkvm and the ioctl
> interface is unavoidable.
If by #ifdeffery you mean having per-architecture definitions of
structures like kvm_regs, absolutely. If you mean literal #ifdefs in the
middle a header file, I believe that can and should be avoided.
> Right now this is handled by qemu, which means our higher level tools
> are _already_ nonportable.
Yes, but not *all* the higher level tools are. At some point you have a
common interface, and at this point I think I've answered my own
question: the qemu monitor connection is the portable interface.
That means everything layered above qemu, such as libvirt and thus
virt-manager, should work on all architectures +/- without changes.
Lower-level software, such as GDB, would need per-architecture support.
> [I have a feeling we're talking a little past each other, probably due
> to me not knowing ppc at any level of detail. No doubt things will
> become clearer when the code arrives]
I don't have any code for you, but you will be the first to know when I
do. :) Right now I'm just trying to make sure we don't accidentally
paint ourselves into a corner with a stable ABI.
-Hollis
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
next prev parent reply other threads:[~2007-03-28 18:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-26 21:20 portability layer? Hollis Blanchard
2007-03-27 6:57 ` Avi Kivity
[not found] ` <4608C06C.2000708-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-03-28 14:26 ` Hollis Blanchard
2007-03-28 15:06 ` Arnd Bergmann
2007-03-28 15:48 ` Avi Kivity
[not found] ` <460A8E44.5080305-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-03-28 18:50 ` Hollis Blanchard [this message]
2007-03-29 7:11 ` Avi Kivity
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=1175107843.1653.69.camel@basalt \
--to=hollis-yux37fbwtuitncamw9vghq@public.gmane.org \
--cc=avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org \
--cc=kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox