1. 16 3月, 2019 4 次提交
    • E
      snapshot: Sort virconftypes.h · 41e3d35e
      Eric Blake 提交于
      It's easier to locate a typedef if they are stored in sorted order;
      do so mechanically via:
      
      $ sed -i '/typedef struct/ {N; N; s/\n//g}' src/conf/virconftypes.h
      $ # sorting the lines
      $ sed -i '/typedef struct/ s/;/;\n/g' src/conf/virconftypes.h
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      41e3d35e
    • E
      conf: Split capabilities forward typedefs into virconftypes.h · 23c15e34
      Eric Blake 提交于
      As explained in the previous patch, collecting pointer typedefs into a
      common header makes it easier to avoid circular inclusions.  Continue
      the efforts by pulling the appropriate typedefs from capabilities.h
      into the new header.
      
      This patch is just straight code motion (all typedefs are listed in
      the same order before and after the patch); a later patch will sort
      things for legibility.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      23c15e34
    • E
      conf: Split domain forward typedefs into virconftypes.h · c555ec24
      Eric Blake 提交于
      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 exception is
      virDomainStateReason, which is only ever used directly rather than via
      a pointer.
      
      This patch is just straight code motion (all typedefs are listed in
      the same order before and after the patch); a later patch will sort
      things for legibility.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      c555ec24
    • E
      object: Add sanity check on correct parent class · 1c560052
      Eric Blake 提交于
      Checking that the derived class is larger than the requested parent
      class saves us from some obvious mistakes, but as written, it does not
      catch all the cases; in particular, it is easy to forget to update a
      VIR_CLASS_NEW when changing the 'parent' member from virObject to
      virObjectLockabale, but where the size checks don't catch that.  Add a
      parameter for one more layer of sanity checking.
      
      It would be cool if we could get gcc to stringize typeof(parent) into
      the string name of that type, so that we could confirm that the
      precise parent class is in use rather than just a struct that happens
      to have the same size as the parent class.  But sizeof checks are
      better than nothing.
      
      Note that I did NOT change the fact that we require derived classes to
      be larger (as the difference in size makes it easy to tell classes
      apart), which means that even if a derived class has no functionality
      to add (but rather exists for compiler-enforced type-safety), it must
      still include a dummy member.  But I did fix the wording of the error
      message to match the code.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      1c560052
  2. 15 3月, 2019 19 次提交
  3. 14 3月, 2019 17 次提交