public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
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

  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