Libvirt Open Source Contribution

[Barrett J Schonefeld]

Hey folks,

We have started work on issue 11
<https://gitlab.com/libvirt/libvirt/-/issues/11>, and we have some
questions to ensure we tackle the issue properly.


   - What are the different use cases for g_autoptr vs g_autofree? We found
   that g_autofree is preferred for anything that uses g_malloc according to
   the Glib documentation
   <https://developer.gnome.org/glib/stable/glib-Miscellaneous-Macros.html#g-autofree>,
   and g_autoptr is for types with custom destructors. However, when using
   g_autoptr, we got compile errors when trying to pass the g_autoptr as an
   argument (the argument seems to be converted to an integer). When should we
   use each of these, and when should we not convert them at all?

   - We see that some work has been done to convert files to use the Glib
   API. In some cases, files contain code that uses both the old memory
   management API and the Glib API. Should we focus our attention on files
   where these conversions are not yet underway? Or should we expect that many
   of the files are only partially converted?

   - In some cases, we found that converting to the Glib API might require
   cascading changes to code structure (function parameter types, function
   return types). Is it advisable to pursue these cases as well, or should we
   limit changes to pointers which are declared and then freed within one
   method?

   - Do you know of a directory or set of files where the conversions to
   the Glib API are needed?


We appreciate the correspondence, and we hope to use this information to
make a good contribution to the project!

Best regards,

Dustan Helm <dustan.helm at yahoo.com>

Barrett Schonefeld <bschoney at utexas.edu>
Ryan Gahagan <ryangahagan18 at gmail.com>

On Wed, Sep 16, 2020 at 4:35 AM Michal Privoznik <mprivozn at redhat.com>
wrote:

> On 9/15/20 10:39 PM, Barrett J Schonefeld wrote:
> > Hey libvirt team,
> >
> >
> > We (Ryan Gahagan, Dustan Helm, and Barrett Schonefeld) are computer
> > science students at the University of Texas at Austin. We are taking a
> > course in virtualization, and we’d like to contribute to the libvirt
> > repository as part of this course. Here are the issues we are most
> > interested in:
> >
> >
> > https://gitlab.com/libvirt/libvirt/-/issues/11
> > <https://gitlab.com/libvirt/libvirt/-/issues/11>
> >
> > https://gitlab.com/libvirt/libvirt/-/issues/16
> >
> >
> > Additionally, we would like to take a look at issue 4
> > (https://gitlab.com/libvirt/libvirt/-/issues/4
> > <https://gitlab.com/libvirt/libvirt/-/issues/4>), the UDP slowdown for
> > QEMU. We expect issue 4 to be more time-intensive, and we would like to
> > communicate with you to ensure we’re solving the problem effectively.
> >
> >
> > Our course only runs until the end of the fall semester, so our time to
> > contribute to this project is somewhat limited. If you think any of the
> > issues we picked would be too difficult to accomplish during that time
> > frame, we would appreciate alternative suggestions. We really hope to
> > contribute to this project and help make improvements where we can.
>
> Hey,
>
> it's always nice to see people interested in libvirt.
>
> Another area that I can offer (not listed on the issues page) is writing
> virsh completers. These are callback functions which are run when a user
> hits <TAB><TAB>, for instance:
>
>    virsh start --domain<TAB><TAB>
>
> brings up a list of shut off guests. It's really regular autocompletion
> like we're used to from bash and/or other projects.
>
> I'd say writing a completer is more beneficial if one wants to learn how
> to use libvirt public APIs because that's basically what a completer
> callback does. I've reviewed some completer patches recently:
>
> https://www.redhat.com/archives/libvir-list/2020-September/msg00592.html
>
> I'm happy to help,
>
> Michal
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20201102/f25dc64d/attachment-0001.htm>