Re: [libvirt] [PATCH 22/49] list: Add helpers to list network objects

On 07/24/2012 08:52 PM, Osier Yang wrote: >>> Or folder the functions into >>> conf/domain_conf.[ch], conf/storage_conf.[ch], etc? >> >> Where is the source data structure defined? If the data structure that >> is used to list of domains/networks/storage pools|volumes is defined in >> conf/*_conf.h, then the function that operates on that data structure to >> produce the output list should be defined in conf/*_conf.c. If the data >> structure is defined in ${driver}.h, then the function that operates on >> it should be defined in ${driver}.c. (I think for all examples in this >> current patchset, the answer is *_conf.c) > > Well. You are a bit late (may be on vacation). virdomainlist.[ch] > is already there. I'd want to see a 3rd opinion on this, if finally > we want them be foldered into *_conf.c, I will be fine with it. > We need to get rid of the existed virdomainlist.[ch] first. My recollection was that Peter originally added virdomainlist.c to solve a link error - our use of virGetDomain() caused a link failure when trying to build the LXC driver. LXC requires several functions from domain_conf.c, but apparently was not linking against the souce for datatypes.c, which made virGetDomain() the first instance of a linking problem. But in the meantime, we have refactored the Makefile, and how LXC is linked in the first place. I'm wondering if Daniel's commit 284143b makes it possible to use virGetDomain() directly from domain_conf.c in the first place. If that is the case, then the answer is 'get rid of virdomainlist.c/virobjectlist.c, and stick everything in the appropriate foo_conf.c instead'. If we still get a link failure for LXC in spite of using virGetDomain() directly from domain_conf.c, then it might be worth investigating that link failure first.

Yeah, that doesn't quite answer the question (one file virobjectlist.c shared among multiple objects, vs. one file per object type), but hopefully it helps in figuring out a way forward.