From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH 3/4] Move KVMState to common header Date: Mon, 08 Jun 2009 17:01:41 -0500 Message-ID: <4A2D8A45.90405@codemonkey.ws> References: <1244488224-31171-1-git-send-email-glommer@redhat.com> <1244488224-31171-2-git-send-email-glommer@redhat.com> <1244488224-31171-3-git-send-email-glommer@redhat.com> <1244488224-31171-4-git-send-email-glommer@redhat.com> <4A2D6C7A.4080008@web.de> <20090608201449.GL11966@poweredge.glommer> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jan Kiszka , kvm@vger.kernel.org, avi@redhat.com To: Glauber Costa Return-path: Received: from mail-qy0-f173.google.com ([209.85.221.173]:55253 "EHLO mail-qy0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752879AbZFHWBp (ORCPT ); Mon, 8 Jun 2009 18:01:45 -0400 Received: by qyk3 with SMTP id 3so126140qyk.33 for ; Mon, 08 Jun 2009 15:01:47 -0700 (PDT) In-Reply-To: <20090608201449.GL11966@poweredge.glommer> Sender: kvm-owner@vger.kernel.org List-ID: Glauber Costa wrote: > On Mon, Jun 08, 2009 at 09:54:34PM +0200, Jan Kiszka wrote: > >> Glauber Costa wrote: >> >>> This patch should be applied to main qemu, but I'll >>> first post it here for appreciation. In this patch, >>> we move KVMState definition to kvm.h header. With this >>> done, we can also use its definition in our files, until >>> there is no more such thing as "our" files. This is too >>> selfish anyway. >>> >>> Later on, we'll move our internal state inside it. >>> >> Well, in upstream no one outside kvm-all.c needs to (and likely should >> be allowed to) access fields from struct KVMState & KVMSlot directly. >> That avoids misuse outside the KVM layer and enforces KVM arch code to >> properly call into the generic layer. >> >> But I see the problem for qemu-kvm's transition time, so let's try to >> find an intermediate solution until its code layout is aligned (I don't >> see any blockers for this). Suggestion: Replicate the relevant >> structures into a new, temporary header. If upstream may extend its >> original structures, this should from now on have happened *first* >> inside qemu-kvm, so no inconsistency can arise unless downstream messed >> it up already. At some point (hopefully not too far away), no user of >> that header will remain and we will be able to drop it again. >> > I'm fine with whatever anthony wants. > I'm fine with either solution as they are both temporary measures... Regards, Anthony Liguori