This may be helpful to everyone if Hollis's explanation of container_of
didn't help:

Lookup up "container_of" or look at the secion named "Lists"
at this link:
http://www.win.tue.nl/~aeb/linux/lk/lk-2.html

It also contains the macro used in the kernel.





On Mon, 2007-10-22 at 14:18 -0500, Hollis Blanchard wrote:
> On Sun, 2007-10-21 at 08:40 +0200, Avi Kivity wrote:
> > 
> > The usage of the macro is only for an intermediate stage, so this
> > patch shows the changes in the data structures, while the next one
> > will be littered with code changes due to the changes in the way
> > fields are addressed.
> 
> OK.
> 
> What is the plan here Xiantao? If I want to begin PPC integration,
> should I submit some patches too (hopefully in areas where we will not
> conflict)? Or should I just review your submissions and hold off on PPC
> code changes until the dust settles?
> 
> > I was initially in favor of doing
> > 
> >     struct kvm_vcpu {
> >         struct kvm_vcpu_common common;
> >         ...
> >     };
> > 
> > in order to avoid the majority of fields requiring an 'arch.' prefix 
> > (most fields are arch dependent, very few are common), but using 
> > container_of() as someone suggested seems to be a better idea. 
> 
> Note: container_of() enables the above layout, and I agree with that
> approach. To avoid misunderstandings, this is what we're talking about:
>         
>         kvm_common_foo(struct kvm_vcpu_common *vcpu)
>         {
>               kvm_arch_foo(vcpu);
>         }
>         
>         kvm_common_bar(struct kvm_vcpu_common *vcpu)
>         {
>               ...
>         }
>         
>         ----------
>         
>         struct kvm_vcpu_ppc440 {
>               struct kvm_vcpu_common common;
>               u32 gpr[32];
>         };
>         
>         #define to_ppc440(v) container_of(...)
>         
>         kvm_arch_foo(struct kvm_vcpu_common *vcpu)
>         {
>               struct kvm_vcpu_ppc440 *ppc440 = to_ppc440(vcpu);
>         
>               ppc440->gpr[3] = 0;
>         
>               kvm_common_bar(ppc440->common);
>         }
>         
> I've chosen specific PPC names since I expect to support more than one
> PowerPC processor type simultaneously, e.g. "modprobe kvm-powerpc-440
> kvm-powerpc-e500". (This will require some additional "kvm_ppc_ops"
> support not shown here.)
> 
> Personally I think "common" is too much typing, but I've left the name
> as you suggested for now. :)
> 


-------------------------------------------------------------------------
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/
_______________________________________________
kvm-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Reply via email to