WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [PATCH 02/17] x86: add io_apic_ops to allow interception

To: Ingo Molnar <mingo@xxxxxxx>
Subject: [Xen-devel] Re: [PATCH 02/17] x86: add io_apic_ops to allow interception
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Wed, 27 May 2009 00:17:27 -0700
Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>, Jens Axboe <jens.axboe@xxxxxxxxxx>, Greg KH <gregkh@xxxxxxx>
Delivery-date: Wed, 27 May 2009 00:29:56 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20090525035446.GC9396@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1242170724-13349-1-git-send-email-jeremy@xxxxxxxx> <1242170724-13349-3-git-send-email-jeremy@xxxxxxxx> <20090525035446.GC9396@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.21 (X11/20090320)
Ingo Molnar wrote:
ok, could you please turn the whole IO-APIC code into a driver framework? I.e. all IO-APIC calls outside of arch/x86/kernel/apic/io_apic.c should be to some io_apic-> method.

The advantage will be a proper abstraction for all IO-APIC details - not just a minimalistic one for Xen's need.

Also, please name it 'struct io_apic' - similar to the 'struct apic' naming we have for the local APIC driver structure.

OK, I'll have a look at it. I think it could turn out quite nicely, and possibly remove the need for some other other Xen hooks around the place, as well as make the path for some other other upcoming things clearer.

But in the meantime, would you consider taking the minimal ops approach for this next merge window, and the full api in the next dev cycle?

Thanks,
   J


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel