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 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.