From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Gregory Haskins" Subject: Re: [PATCH 5/9] KVM: Adds ability to signal userspace using a file-descriptor Date: Tue, 15 May 2007 12:55:10 -0400 Message-ID: <4649AD87.BA47.005A.0@novell.com> References: <20070515145404.15609.61552.stgit@novell1.haskins.net> <20070515145759.15609.34720.stgit@novell1.haskins.net> <4649E22F.3090308@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: "Anthony Liguori" Return-path: In-Reply-To: <4649E22F.3090308-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org >>> On Tue, May 15, 2007 at 12:39 PM, in message <4649E22F.3090308-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>, Anthony Liguori wrote: > This patch series depends on eventfd which means that KVM now requires > 2.6.22- rc1. This is understood. > > While KVM will inevitably start requiring newer kernel versions, do we > really need to do it right now? Perhaps we could add dummy eventfd_* > functions to the module compat header? Then at least older kernels will > continue to work with in- kernel APIC disabled. > The plan as Avi and I agreed to (IIUC) is to support eventfd via the extern-compat header. The same could be said for HRT. I don't thing either one will be particularly pleasant to support in this fashion, but this is how he wants to do it. (Recall that I had abstracted the HRT in earlier versions which he requested to be removed, so I didnt bother with the eventfd interface). I agree that it will keep the kvm core code cleaner instead of having all these custom abstractions, so I see his point there. I'm just not looking forward to the compat work ;) That being said: Perhaps you just came up with a good compromise. The code is already structured to support both the old way and the new way. We could have the in-kernel modes disabled at compile time on older kernels. Thats probably a much better solution then trying to get HRT and eventfd emulated on, say, 2.6.9 ;) The implication here is that I don't plan on supporting new features via the old-way. For instance, SMP features would only work with in-kernel emulation. If we go down this route, it automatically means that older kernels will not have any other related advanced features, not just the performance/features currently offered. Perhaps this is acceptable also? I'm not sure. Regards, -Greg ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/