Re: [kvm-ppc-devel] [PATCH 1 of 3] Move x86 kvmcallback structure tokvmctl-x86.h header

[Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>]

Hollis Blanchard wrote:
> On Mon, 2007-10-29 at 10:41 +0800, Zhang, Xiantao wrote:
>   
>> Anthony Liguori wrote:
>>     
>>> Hollis Blanchard wrote:
>>>       
>>>>> I don't know the privious story about this thread, but now I can't
>>>>> understand the move. Why do we move all the structure to
>>>>> arch-specific ? For IA64 side, almostly we can reuse them directly,
>>>>> and just see some special fields as arch-specific. So, I think, we
>>>>> should keep common fields in kvmctl.h. 
>>>>>
>>>>>           
>>>> Are you suggesting that kvm_callbacks should be the union of all
>>>> callbacks used on all architectures, and for any given architecture
>>>> only a subset are actually used? 
>>>>
>>>>         
>>> I think two separate callback structures would make more sense.
>>>
>>> Quite a few of the callbacks should have common implementations.  For
>>> instance, all of the io callbacks and the io_window callback should be
>>> the same.  I would expect most architectures have a concept of a
>>> "halt" so that should probably be the same too.  That pretty much
>>> covers the majority of the callbacks structure :-)
>>>       
>> Agree. 
>>     
>
> OK, are you changing your position then? Anthony is saying there should
> be multiple callback data structure definitions, but that the
> *implementations* of some of those callbacks should be shared. For
> example:
>
> ia64.h:
>         struct kvm_callbacks {
>                 ...
>                 .inb = pio_inb,
>         };
>
> x86.h:
>         struct kvm_callbacks {
>                 ...
>                 .inb = pio_inb,
>         };
>
> pio.c (built only for ia64 and x86):
>         int pio_inb(port) {
>                 ...
>         }
>   

I was actually advocating splitting the kvm_callbacks structure into two 
separate structures, one being architecture specific.  But I don't think 
it's *that* important.

Regards,

Anthony Liguori



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