Difference between revisions of "BiteSizedTasks"

From Libvirt Wiki
Jump to: navigation, search
(Remove the *DefNew additions, could be contentious and value is unclear)
 
(43 intermediate revisions by 5 users not shown)
Line 1: Line 1:
 
This page tracks introductory tasks for new libvirt contributors. Code cleanups, bugs, and small features are listed with difficulty ranging from trivial to intermediate.
 
This page tracks introductory tasks for new libvirt contributors. Code cleanups, bugs, and small features are listed with difficulty ranging from trivial to intermediate.
  
== Introductory bug reports (LibvirtFirstBug) ==
+
These tasks are good first introductions to libvirt code. You will be required to get things building and make sure the test suite passes, but not necessarily need to understand the details of what libvirt is doing. Mostly these are following existing example changes that are already in the code. Contact the listed mentor with any questions
  
Some bugs in the libvirt bugzilla tracker are marked as good introductory bug reports for new contributors. These bugs have the 'LibvirtFirstBug' tag. Each bug report contains info and sample commits to point you in the right direction. You can open the list in your browser bugzilla [https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=POST&bug_status=MODIFIED&classification=Community&f1=status_whiteboard&f2=component&list_id=4807856&o1=substring&o2=anywordssubstr&product=Virtualization%20Tools&query_format=advanced&v1=LibvirtFirstBug&v2=libvirt here].
+
These tasks are all tracked as [https://gitlab.com/libvirt/libvirt/-/issues?label_name=bitesizedtask issues with the bitesizedtask tag]
 
 
<rss templatename="Template:RSSBugzillaTemplate" max=500>https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=POST&bug_status=MODIFIED&classification=Community&f1=status_whiteboard&f2=component&list_id=4999130&o1=substring&o2=anywordssubstr&order=bug_id&product=Virtualization%20Tools&query_based_on=&query_format=advanced&v1=LibvirtFirstBug&v2=libvirt&ctype=atom</rss>
 
 
 
== Enhancements ==
 
 
 
=== Move virDomainVideoDefaultType logic to individual drivers ===
 
 
 
Mentor: Cole Robinson <crobinso@redhat.com>
 
 
 
The virDomainVideoDefaultType function in src/conf/domain_conf.c shouldn't be there :) The logic setting a device default should be in the post parse function of individual driver code.
 
 
 
See this example commit that moves logic out of that function and into the qemu driver: https://github.com/libvirt/libvirt/commit/ef08a545388f388b7c76b99a3f3d2584daf05145
 
 
 
=== Move default Input bus logic to PostParse handling ===
 
 
 
Mentor: Cole Robinson <crobinso@redhat.com>
 
 
 
Similar to what was started with default video model logic in these commits:
 
 
 
https://github.com/libvirt/libvirt/commit/a2ca7ca52eb624883ac5a7e1d5deebb43981a410
 
https://github.com/libvirt/libvirt/commit/29a90f071dd7c1764f82c7fcbfdded35d252b174
 
https://github.com/libvirt/libvirt/commit/ef08a545388f388b7c76b99a3f3d2584daf05145
 
 
 
Break out the default bus setting logic from virDomainInputDefParseXML and move it to PostParse handling. Look for anything that sets a def->bus value in that function, it's grounds for removal
 
 
 
=== Add additional virsh command line completion functions ===
 
 
 
Mentor: Michal Privoznik <mprivozn@redhat.com>
 
 
 
Completers are small functions that are called from the virsh command line tool whenever the user started typing something and hit TAB TAB. Their purpose is to offer list of strings that suit entered input. If there is only one item on the list then it's entered in automatically. For instance:
 
 
 
virsh # dom<TAB><TAB>
 
domblkerror        domblkstat          domcontrol          domfsinfo ..
 
 
 
virsh # start --domain <TAB><TAB>
 
fedora      fedora.i686  freebsd      gentoo ...
 
 
 
Additional functions are needed to improve other commands.
 
 
 
An example patch: https://www.redhat.com/archives/libvir-list/2018-June/msg01672.html
 
A series of example patches: https://www.redhat.com/archives/libvir-list/2018-January/msg00436.html
 
 
 
== Code Cleanups ==
 
 
 
==== Add function for XML yes|no string handling ====
 
 
 
Mentor: Cole Robinson <crobinso@redhat.com>
 
 
 
There's a common pattern in our XML parsing to convert string 'yes' in true and 'no' into false, and error if we receive anything other than those values. To find instances, try git grep "(STREQ(.*, \"yes\")" and git grep "(STREQ(.*, \"no\")"  . We should add a function in src/util/virstring.c to centralize the logic, like:
 
 
 
int virStringParseYesNo(const char *str, bool *result)
 
 
 
Bonus if it is extended to raise a specialized error message to convert the value
 
 
 
==== Split apart virDomainObjAssignDef() ====
 
 
 
Mentor: Cole Robinson <crobinso@redhat.com>
 
 
 
The virDomainObjAssignDef() function takes 4 arguments, the latter 2 'live' and 'oldDef' are very rarely used. The function should be reworked to provide 3 functions instead:
 
 
 
* Rename virDomainObjAssignDef() to virDomainObjAssignDefGetOldDef()
 
* Add virDomainObjAssignDefLive(arg1, arg2) which does virDomainObjAssignDefGetOldDef(arg1, arg2, true, NULL);
 
* Add virDomainObjAssignDef(arg1, arg2) which does virDomainObjAssignDefGetOldDef(arg1, arg2, false, NULL);
 
 
 
All the callers will need to be adjusted, but it will be much more clear what those callers actually do.
 
 
 
==== Move validation checks out of domain XML parsing ====
 
 
 
Mentor: Cole Robinson <crobinso@redhat.com>
 
 
 
The code that handles domain/VM XML parsing (virDomainDefParseXML in src/domain/domain_conf.c) has various validation checks sprinkled within it. Many of these checks should be moved out of the parse step and into virDomainDefPostParse, so they can be shared by various places in the code that build a domain definition without XML, such as converting from native vmware/virtualbox/xen formats.
 
 
 
Not all validation checks can or should be moved. You'll need to determine if the check is specific to the actual XML parsing, or is it general for all VM configurations. So anything that throws an error if it hits unexpected XML should not be moved.
 
 
 
Just a few of the candidates for moving to virDomainDefPostParse:
 
* All the errors in virDomainDefParseXML containing the string "usb is disabled"
 
* All the errors in virDomainDefParseXML containing the string "period must be in range"
 
* All the errors in virDomainDefParseXML containing the string "quota must be in range"
 
* All the checks against dom->os.type and dom->virtType in virDomainInputDefParseXML should go into a virDomainInputDefValidate function
 
* The error "tray is only valid for cdrom and floppy"
 
* The error "removable is only valid for usb disks"
 
* Many other checks in virDomainDiskDefParseXML
 
 
 
==== Share cgroup code that is duplicated between QEMU and LXC ====
 
 
 
Mentor: Cole Robinson <crobinso@redhat.com>
 
 
 
<b>INTERMEDIATE</b>: Both QEMU and LXC drivers have some similar code when dealing with cgroups. See various routines in src/lxc/lxc_cgroup.c and src/qemu/qemu_cgroup.c, there is lots of opportunity for centralizing functionality in src/util/vircgroup.c. For example:
 
 
 
* virLXCCgroupSetupBlkioTune() and qemuSetupBlkioCgroup() are similar
 
* virLXCCgroupSetupCpuTune() and qemuSetupCpuCgroup() are similar
 
 
 
==== Share duplicated daemon code ====
 
 
 
Mentor: Cole Robinson <crobinso@redhat.com>
 
 
 
<b>INTERMEDIATE</b>: Libvirt ships several daemons (libvirtd, virtlogd, virtlockd) that all have similar code around general daemon startup. Right now the code is duplicated for each daemon, but it could be shared, like in a new file src/util/virdaemon.c. The main files to look in are src/logging/log_daemon.c, src/locking/lock_daemon.c, and daemon/libvirtd.c. Some example functions to look at:
 
 
 
* the *ForkIntoBackground functions
 
* the *SetupLogging functions
 
* the *SetupSignals functions
 
* the *DaemonClientNew functions
 
* the *UnixSocketPaths functions
 
 
 
==== Clean up virQEMUDriverPtr parameters ====
 
 
 
Mentor: Martin Kletzander <mkletzan@redhat.com>
 
 
 
<b>BEGINNER</b>: Many functions in the QEMU driver code (src/qemu/) take both a domain object and a driver as a parameter.  However, since 2e6ecba1bcac, a pointer to the driver structure is saved in private data of the domain object.  That can be used instead of a parameter being passed to various functions (a git grep for 'virQEMUDriverPtr driver,' shows some applicable candidates).
 
 
 
Example patch: https://www.redhat.com/archives/libvir-list/2017-July/msg01068.html
 
 
 
==== Clean up virBufferCheckError() callers ====
 
 
 
Mentor: Martin Kletzander <mkletzan@redhat.com>
 
 
 
<b>BEGINNER</b>: There is a concept of dynamically allocated buffer in libvirt, called virBuffer.  One of its advantages is that functions working with this buffer do not report error or have any return value.  The error is stored in the structure itself.  While long-winded manipulations with virBuffer are easy and clean thanks to this (no need to check for error after every single append of data), the disadvantage is that every time the data is received from the buffer there needs to be check for the possibility of an error and the data received.  These two things are not always needed both or done together, however in most places it is.  While this handling needed a condition and a check, it is now a little bit easier to do this and older code should be cleaned up to use the new approach.
 
 
 
Example patch: https://www.redhat.com/archives/libvir-list/2017-August/msg00562.html
 
 
 
==== More conversions to virErrorPreserveLast/virErrorRestore ====
 
 
 
Mentor: Cole Robinson <crobinso@redhat.com>
 
 
 
virErrorPreserveLast + virErrorRestore are newer internal APIs for saving and restoring error reports. 'git grep virSaveLastError' and most usages will be candidates for converting.
 
 
 
See this commit for example conversions in qemu_hotplug.c: https://github.com/libvirt/libvirt/commit/6f18150f7b61c3671622d29dba816247454616a1
 
 
 
==== Clean up variables in tools/libvirt-guests.sh.in ====
 
 
 
<b>BEGINNER</b>: The script has many functions that just redeclare variables all over the place instead of making them local to the function using the `local` keyword.  There might be some errors due to the rewriting of the variables and it's also prone to error, so all such variables should be marked `local`.  There is at least one function that returns an information in a variable.  Such occurrences might be fixed up or kept that way.
 
 
 
==== Change testutils.[ch] referencing in tests/Makefile.am ====
 
 
 
<b>BEGINNER</b>: Go through the rules in the file and see how can the files `testutils.[ch]` be referenced so that the rules are smaller.  There are various ways how to do that and it is left as an exercise to the implementer to figure out which one is the best.  And to possibly discuss that on the list.
 
 
 
Ideas include:
 
 
 
* Create object file of testutils and add that to each tests' testname_LDADD
 
* Add it to LDADD in that file so that it's included in all the tests
 
* Create a variable TESTUTILS and use that instead of testutils.[ch]
 
* etc.
 
 
 
==== Remove redundant uses of *.la in Makefiles ====
 
 
 
<b>BEGINNER</b>: There is variable LDADDS in most of the Makefiles that is used for most of the targets in the Makefile.  So specifying it separately just pollutes the file for no benefit.  Check for such cases, fix them and think of a way automatically checking whether that happens.
 
 
 
=== More conversions from VIR_FREE to VIR_AUTO(FREE|PTR|CLOSE) aka automatic freeing of resources ===
 
 
 
<b>BEGINNER</b>: Both gcc and clang implement the <code>__attribute__((cleanup))</code> which
 
triggers the defined function call whenever variable marked with this attribute goes
 
out of the scope. This can be leveraged in a number of scenarios, but in libvirt this is mainly about memory deallocation in an automated manner.
 
 
 
An example patch:
 
https://www.redhat.com/archives/libvir-list/2018-August/msg00432.html
 

Latest revision as of 15:17, 17 April 2020

This page tracks introductory tasks for new libvirt contributors. Code cleanups, bugs, and small features are listed with difficulty ranging from trivial to intermediate.

These tasks are good first introductions to libvirt code. You will be required to get things building and make sure the test suite passes, but not necessarily need to understand the details of what libvirt is doing. Mostly these are following existing example changes that are already in the code. Contact the listed mentor with any questions

These tasks are all tracked as issues with the bitesizedtask tag