[PATCH 6/6] lib: Drop internal virXXXPtr typedefs

Daniel P. Berrangé berrange at redhat.com
Thu Mar 11 18:47:37 UTC 2021


On Thu, Mar 11, 2021 at 06:54:20PM +0100, Michal Privoznik wrote:
> Historically, we declared pointer type to our types:
> 
>   typedef struct _virXXX virXXX;
>   typedef virXXX *virXXXPtr;
> 
> But usefulness of such declaration is questionable, at best.
> Unfortunately, we can't drop every such declaration - we have to
> carry some over, because they are part of public API (e.g.
> virDomainPtr). But for internal types - we can do drop them and
> use what every other C project uses 'virXXX *'.
> 
> This change was generated by a very ugly shell script that
> generated sed script which was then called over each file in the
> repository. For the shell script refer to the cover letter:
> 
> $URL
> 
> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
> ---
>  docs/advanced-tests.rst                       |    2 +-
>  docs/api_extension.html.in                    |    2 +-
>  docs/coding-style.rst                         |    2 +-

snip

>  tools/virt-login-shell-helper.c               |    4 +-
>  tools/vsh-table.c                             |   36 +-
>  tools/vsh-table.h                             |   12 +-
>  tools/vsh.c                                   |    4 +-
>  732 files changed, 29237 insertions(+), 30131 deletions(-)

Converting every single file at the same time in one commit is
guaranting backporting conflict hell.

eg if I'm backporting a patch from src/qemu, it is much
saner if I can cherry-pick the "Ptr" conversion from src/qemu
and only deal with conflicts in that, not the entire soure
tree.

So if we're going to do this conversion, IMHO the actual commits
need to be way more granular. At the very least I think this
needs to be split per driver, with tests/ associated with their
driver. The util/ directory needs to be split up and likewise
the conf/ directory per object type I think.

Also dropping usage of the "Ptr" should be separate from dropping
the typedefs themselves as I think that'll make conflicts easier
to deal with.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




More information about the libvir-list mailing list