From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC] lapic3: cleanup for save/restore data structure of in-kernel irqchips Date: Fri, 03 Aug 2007 17:57:41 +0300 Message-ID: <46B34265.1040307@qumranet.com> References: <37E52D09333DE2469A03574C88DBF40F048EDA@pdsmsx414.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0501069194==" Cc: kvm-devel To: "He, Qing" Return-path: In-Reply-To: <37E52D09333DE2469A03574C88DBF40F048EDA-wq7ZOvIWXbM/UvCtAeCM4rfspsVTdybXVpNB7YpNyf8@public.gmane.org> 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 --===============0501069194== Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable He, Qing wrote: > =20 >> -----Original Message----- >> From: Avi Kivity [mailto:avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org] >> Sent: 2007=C4=EA8=D4=C22=C8=D5 19:58 >> To: He, Qing >> Cc: kvm-devel >> Subject: Re: [kvm-devel] [RFC] lapic3: cleanup for save/restore data s= tructure of >> in-kernel irqchips >> >> He, Qing wrote: >> =20 >>> Hi, >>> The argument of in-kernel irqchip save/restore IOCTL uses a >>> separate data structure (struct kvm_irqchip and struct kvm_ioctl_pic = in >>> include/linux/kvm.h) different from functional data structure (struct >>> kvm_pic_state and struct kvm_ioapic in driver/kvm/irq.h), this is >>> because while most data are used at both side, there are certain >>> internal data in functional data structure which should not be expose= d >>> to the user. >>> Current code has some duplication between these two, and these >>> duplicated parts are copied back and forth when save and restore. Thi= s >>> seems a maintenance pain. >>> >>> =20 >> I'm not sure consolidating helps with maintenance in this case: >> >> - if there are no changes, there is no maintenance. >> =20 > > Well, I don't think we can safely presume the code will never change. F= or example, maybe someone wants to make IOAPIC redir table count dynamica= lly configurable, or consolidate IOSAPIC support into current IOAPIC code= , etc. In these cases, the duplicated data structure is capable to become= a trap. > Furthermore, even if there is no maintenance concern, these codes are = still not elegant enough. > =20 The point is, if we de-duplicate the structure now, we'll have to re-duplicate it when it changes, because we'll have to maintain compatibility. > =20 >> - if we change the kernel side, we can't change the userspace interfac= e >> side because it will break existing code. we have to write a new data >> structure for the interface and maintain the new and the old in parall= el. >> =20 > > I don't see your concern here. The whole lapic3 is work in progress, is= n't it? Why should we maintain an `old' interface? Also, as in the second= patch, no userspace change is required. > =20 I was thinking about maintenance post 2.6.24. However, I'm not opposed to the second patch -- if you think it worthwhile, it can go in. --=20 error compiling committee.c: too many arguments to function --===============0501069194== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ --===============0501069194== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ kvm-devel mailing list kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org https://lists.sourceforge.net/lists/listinfo/kvm-devel --===============0501069194==--