Re: [RFC] lapic3: cleanup for save/restore data structure of in-kernel irqchips

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2345 bytes --]

He, Qing wrote:
>   
>> -----Original Message-----
>> From: Avi Kivity [mailto:avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org]
>> Sent: 2007年8月2日 19:58
>> To: He, Qing
>> Cc: kvm-devel
>> Subject: Re: [kvm-devel] [RFC] lapic3: cleanup for save/restore data structure of
>> in-kernel irqchips
>>
>> He, Qing wrote:
>>     
>>> 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 exposed
>>> to the user.
>>> 	Current code has some duplication between these two, and these
>>> duplicated parts are copied back and forth when save and restore. This
>>> seems a maintenance pain.
>>>
>>>       
>> I'm not sure consolidating helps with maintenance in this case:
>>
>> - if there are no changes, there is no maintenance.
>>     
>
> Well, I don't think we can safely presume the code will never change. For example, maybe someone wants to make IOAPIC redir table count dynamically 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.
>   

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.

>   
>> - if we change the kernel side, we can't change the userspace interface
>> 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 parallel.
>>     
>
> I don't see your concern here. The whole lapic3 is work in progress, isn't it? Why should we maintain an `old' interface? Also, as in the second patch, no userspace change is required.
>   

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.

-- 
error compiling committee.c: too many arguments to function



[-- Attachment #2: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #3: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel