On 07/17/2015 05:27 AM, Michal Privoznik wrote:
Our domain_conf.* files are big enough. Not only they contain XML
parsing code, but they served as a storage of all functions whose
name is virDomain prefixed. This is just wrong as it gathers not
related functions (and modules) into one big file which is then
harder to maintain. Split virDomainObjList module into a separate
file called virdomainobjlist.[ch].
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
BTW: this is the first patch of my attempt to merge
virDomainObjList and virNetworkObjList together into one
virObjectList as the code is pretty much duplicated between the
two.
I know the patch is rather big, but this all needs to be done in
a single commit if we want to remain compile-able after each
commit.
po/POTFILES.in | 1 +
src/Makefile.am | 3 +-
src/conf/domain_conf.c | 901 ----------------------------------------
src/conf/domain_conf.h | 115 ------
src/conf/nwfilter_conf.h | 2 +-
src/conf/virdomainobjlist.c | 966 +++++++++++++++++++++++++++++++++++++++++++
src/conf/virdomainobjlist.h | 146 +++++++
src/esx/esx_driver.c | 2 +-
src/hyperv/hyperv_driver.c | 2 +-
src/libvirt_private.syms | 35 +-
src/libxl/libxl_conf.h | 2 +-
src/openvz/openvz_conf.h | 2 +-
src/test/test_driver.c | 1 +
src/uml/uml_conf.h | 2 +-
src/util/virclosecallbacks.h | 2 +-
src/vbox/vbox_common.c | 2 +-
src/vmware/vmware_conf.h | 2 +-
src/vz/vz_utils.h | 2 +-
tools/virsh-domain-monitor.c | 2 +-
19 files changed, 1146 insertions(+), 1044 deletions(-)
create mode 100644 src/conf/virdomainobjlist.c
create mode 100644 src/conf/virdomainobjlist.h
If domainobj and networkobj are going to merge, then does this
virdomainobjlist.{c|h} only exist for a short time? I would think
virObjectList* API's would continue in virobject.{c|h}. I know this
patch is mostly code motion, but it impacts and is impacted by on list
patches (say nothing of backport/merge resolution issues).
If it's only going to "last" a short while, then it just seems more
"reasonable" to create new/clean virObjectListXXX API's with lock/ref
mgmt "built in". Each could be "created" using existing/similar
Domain/Network APIs. There are certain API's that are already the same,
but others that have slight differences in the way they access the data
as well as some specific content.
John