-
Notifications
You must be signed in to change notification settings - Fork 95
How to Contribute to GVTg Project
Checking out the developing code from: https://github.com/intel/gvt-linux.git with gvt-staging branch.
Share your ideas and thoughts with other developers in the development mailing list: intel-gvt-dev@lists.freedesktop.org
There are several flexible ways to contribute to Intel GVT-g open source project for developers with different levels of knowledge and experience. This section is for the beginner who may wish to contribute to the project with few experience of open source project development. A possible task list for beginners should be:
- Refine the message of error reporting
The error reporting message in the code might not be suitable anymore because of the changes of coding path and coding re-factor, or it could be vague and not report a clear message to the developer during code debugging. Also some error report might not be in a suitable error level.
- Refine the coding block layout
Some coding block might violate the kernel coding styles or even just seems not perfect for developers to read. This could happen during the heavy code changes.
- Refine the name of functions
For those functions which are called from other files or perhaps different modules, usually their name begins with “intel_gvt” if they are functions related to generic frameworks. For functions which are specifically deal with vGPUs, their names would start with prefix “intel_vgpu”. All of the static functions should not start with intel_gvt or intel_vgpu.
For functions names, “[prefix] + verb + something” is the most preferred way in Intel GVT-g.
- Refine the name of variables
It is known that the name of some variables has unique meanings. E.g. “ret” == return value. But sometimes different developer might have different understandings. Don’t hesitate to drop an email to mailing list if you find some names are not suitable.
- Remove extra white space and blank lines
If a whitespace or blank line is found in the code occasionally, it should be fixed immediately
- Complier warnings
Due to the upgrade of the complier in the system, some new warnings might show up. Or different kernel configuration also could lead to complier warnings or even errors.
Now you have your first modification of the project. Make sure the kernel can be successfully compiled with your modification
- Be sure to configure your personal information first. This only needs to be done once after git is setup
git config --global user.name “[First name] [Last name]” #or [Last name], [First name]
git config --global user.email “Your Email”
Now you can execute “git commit -a -s” to contain your change into a git commit and you have to write the patch title and comment body.
- Make sure the title of the patch clearly show what it does.
E.g. >Bad: “Fix something couldn’t work” >Good: “Fix a memory leak in xxx”
A common title of patch to GVT-g would start with “drm/i915/gvt: ”
- Each line of the comment body should not exceed 75 characters, or scripts/checkpatch.pl would complain.
- Explain the problem and how you solve it briefly in the comment body, but be sure to explain the limitation of your solution and what bad thing would happen without this patch if it fixes a critical problem.
Now a new git commit is in your git tree. Use “git format-patch” to export it.
- Before sending it to the mailing list, be sure to perform patch checking via “scripts/checkpatch.pl” and fixes all the warnings and errors if your patch has some style problem.
Now you can send it to the GVT mailing list by “git send-email”. It’s very important to send the mail by git send-email command as different MUAs would have different configuration of mail format.
Read more about submitting patches to Linux kernel at:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html