Re: [GSoC] Interested Student for the Project: 'Introducing job control to the storage driver'
On 23. 3. 2020 10:45, Prathamesh Chavan wrote:
Hi Everyone,
Hey!
It's nice to see somebody new interested in libvirt.
I'm Prathamesh Chavan, a final year student at studying Computer
Science and Engineering at IIT Kharagpur. I've been part of GSoC'17
under the Git Organization and have an internship experience at
Nutanix, India during last summer.
I'm also currently working on a tired file system with software wear
management for nvm technologies as my master project.
I was interested in contributing to the project: "Introducing job
control to the storage driver" under Google Summer of Code - 2020.
I was currently going through the codebase and also was successfully
able to build it.
It would be great if I was assigned a byte-task regarding the same
which could help me understand the project better,
There is no assignment process, just pick anything you want. Adapting to
GLib is pretty popular as it usually removes some lines :-) But feel
free to pick anything you would like.
And for the GSoC project itself; we currently have in_use member for
virStorageVolDef structure which serves as a refcounter. Then we have
some mutexes to guard access to the counter. Whenever a 'long running'
storage API is called (e.g. virStorageVolWipe(),
virStorageVolDownload(), ...) the refcounter is increased at the
beginning and then decreased at the end. Then, virStorageVolDelete()
checks this refcounter to see if there is some other thread using it.
But we already have something similar implemented for virDomainObj -
jobs. Whenever an API wants to work with a domain object [1], it shall
acquire a job. This job then prevents other threads from modifying the
object meanwhile The threads wanting to work over the same object will
serialize. The whole job control is described in src/qemu/THREADS.txt so
I would start there.
Michal
1: actually, that is not entirely true. Acquiring a job is required only
for those APIs which want to unlock the domain object in the middle.
Therefore, some 'short' APIs have no job acquiring implemented (e.g.
qemuDomainGetInfo()). But some other 'short' APIs do (e.g.
qemuDomainReset()).