From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: [RFC PATCH v3 5/6] kvm/ppc/mpic: in-kernel MPIC emulation Date: Thu, 4 Apr 2013 18:33:38 -0500 Message-ID: <1365118418.14772.22@snotra> References: <20130404055902.GL3889@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Content-Transfer-Encoding: 8BIT Cc: Alexander Graf , , , To: Gleb Natapov Return-path: In-Reply-To: <20130404055902.GL3889@redhat.com> (from gleb@redhat.com on Thu Apr 4 00:59:02 2013) Content-Disposition: inline Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 04/04/2013 12:59:02 AM, Gleb Natapov wrote: > On Wed, Apr 03, 2013 at 03:58:04PM -0500, Scott Wood wrote: > > KVM_DEV_MPIC_* could go elsewhere if you want to avoid cluttering > > the main kvm.h. The arch header would be OK, since the non-arch > > header includes the arch header, and thus it wouldn't be visible to > > userspace where it is -- if there later is a need for MPIC (or > > whatever other device follows MPIC's example) on another > > architecture, it could be moved without breaking anything. Or, we > > could just have a header for each device type. > > > If device will be used by more then one arch it will move into > virt/kvm > and will have its own header, like ioapic. virt/kvm/ioapic.h is not uapi. The ioapic uapi component (e.g. struct kvm_ioapic_state) is duplicated between x86 and ia64, which is the sort of thing I'd like to avoid. I'm OK with putting it in the PPC header if, upon a later need for multi-architecture support, it could move into either the main uapi header or a separate uapi header that the main uapi header includes (i.e. no userspace-visible change in which header needs to be included). -Scott