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

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

 



On 2012年07月31日 01:00, Eric Blake wrote:
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.

I tried, virGetDomain can be used without including virdomainlist.h,
seems Daniel's commit fixed the link error.


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.

I think your opinion is to destroy virdomainlist.h then. Assuming it
as a 3rd opinion, I will go this way, and rebase the whole patch set.
Thanks!

Regards,
Osier

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