Hey folks,
We have started work on issue 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, 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,
On Wed, Sep 16, 2020 at 4:35 AM Michal Privoznik <mprivozn@xxxxxxxxxx> 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
