Paul Turner wrote: > On 7/18/07, Anthony Liguori <[EMAIL PROTECTED]> 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/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
