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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

-- 
Eric Blake   eblake@xxxxxxxxxx    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]