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@xxxxxxxxxx>
> ---
>
> 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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list