Re: [PATCH] move structures to svm/vmx.c, use untyped arch_data in independent code

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

Paul Turner wrote:
> On 7/18/07, Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org> wrote:
>   
>> Paul Turner wrote:
>>     
>>> I mentioned that as a possible solution in the other thread.  The
>>> memorystructure  gets a little uglier in that case since you have to
>>> hang the relevant vcpu off kvm_struct, in addition to throwing the
>>> container_of macro pretty much everywhere since the arch indep code
>>> can only obviously only pass kvm_vcpus, I don't really like the macro
>>> approach either I just don't see anything nicer right now..
>>>       
>> Well, let me show you what I mean:
>>     
>
> I considered this approach as well and am happy to refactor it in this
> form if that's what Avi wants; I still think it's nicer not to invert
> these structures but am relatively ambivalent :)
>
>   

As this is the standard way of doing things, and as the 
zero-length-array idea failed miserably, this is probably the best solution.

>>>>>   struct vmcs *vmcs;
>>>>>           
>> +     struct kvm_vcpu vcpu;
>>
>>     
>
> In this approach you might as well embed that at the start so that the
> arch independent code can still allocate/free, that or move the memory
> alloc/dealloc entirely to the arch specific code.  Although that
> should probably be done anyway with this approach otherwise it's not
> clear exactly what is occurring from the arch independent code path's
> pov.
>   

Yes, the arch independent stuff should be at the start.


[...]

People, trim your quotes!



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


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