From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [RFC PATCH v3 5/6] kvm/ppc/mpic: in-kernel MPIC emulation Date: Mon, 8 Apr 2013 13:39:17 +0300 Message-ID: <20130408103917.GC7724@redhat.com> References: <20130404055902.GL3889@redhat.com> <1365118418.14772.22@snotra> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alexander Graf , kvm-ppc@vger.kernel.org, kvm@vger.kernel.org, paulus@samba.org To: Scott Wood Return-path: Content-Disposition: inline In-Reply-To: <1365118418.14772.22@snotra> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On Thu, Apr 04, 2013 at 06:33:38PM -0500, Scott Wood wrote: > 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). > Agree, it make sense to have separate uapi header for a device that is used by more then one arch. -- Gleb.