Re: [libvirt] [PATCH v6 1/8] snapshot: Split domain forward typedefs into new file

[ not sure how John Snow got on the CC list. Hi, John! ] s/snapshot/conf/ in the summary

On Fri, Mar 15, 2019 at 12:02:26AM -0500, Eric Blake wrote: > Right now, snapshot_conf.h is rather large - it deals with three > separate types: virDomainSnapshotDef (the snapshot definition as it > maps to XML), virDomainSnapshotObj (an object containing a def and the > relationship to other snapshots), and virDomainSnapshotObjList (a list > of snapshot objects), where two of the three types are currently > public rather than opaque.  What's more, the types are circular: a > snapshot def includes a virDomainPtr, which contains a snapshot list, > which includes a snapshot object, which includes a snapshot def. > > In order to split the three objects into separate files, while still > allowing each header to use sane typedefs to incomplete pointers, the > obvious solution is to lift the typedefs into yet another header, with > no other dependencies.  Start the split by factoring out all struct > typedefs from domain_conf.h (enum typedefs don't get used in function > signatures, and function typedefs tend not to suffer from circular > referencing, so those stay put).  The only other excpetion is exception

> # include "internal.h" > +# include "virconftypes.h" The files in src conf do not use the vir prefix. How about "conf_types.h"?

> # include "capabilities.h" > # include "virstorageencryption.h" > # include "cpu_conf.h" > diff --git a/src/conf/virconftypes.h b/src/conf/virconftypes.h > new file mode 100644 > index 0000000000..0e0dc3da03 > --- /dev/null > +++ b/src/conf/virconftypes.h > @@ -0,0 +1,278 @@ > +/* > + * virconftypes.h: struct typedefs to avoid circular inclusion > + *    (derived from domain_conf.h) I don't think this line is necessary

> + * > + * Copyright (C) 2006-2019 Red Hat, Inc. > + * Copyright (C) 2006-2008 Daniel P. Berrange > + * Copyright (c) 2015 SUSE LINUX Products GmbH, Nuernberg, Germany. Possibly inaccurate, but better than omitting it.

Reviewed-by: Ján Tomko <jtomko(a)redhat.com&gt; Jano