Open CAS is distributed on BSD-3-Clause license. Please navigate here for full license text.
Issues and potential feature requests are tracked using Github Issues mechanism. It is advised to label issue to indicate its type (e.g. defect, feature request, etc.)
When submitting a defect report it is advised to provide all the relevant information to reproduce the issue. This ideally includes:
- HW configuration, such as: CPU used, memory, disk, etc.
- SW configuration, such as: Linux distribution version, Linux kernel version.
- Steps to reproduce (e.g. simple script with indication failing steps).
Reporting a Potential Security Vulnerability
If you have discovered potential security vulnerability in this project, please send an e-mail to email@example.com. For issues related to Intel Products, please visit https://security-center.intel.com.
It is important to include the following details:
- The projects and versions affected
- Detailed description of the vulnerability
- Information on known exploits
Vulnerability information is extremely sensitive. Please encrypt all security vulnerability reports using our PGP key
A member of the Intel Product Security Team will review your e-mail and contact you to to collaborate on resolving the issue. For more information on how Intel works to resolve security issues, see: Vulnerability Handling Guidelines
PGP Key: https://www.intel.com/content/www/us/en/security-center/pgp-public-key.html
Vulnerability Handling Guidelines: https://www.intel.com/content/www/us/en/security-center/vulnerability-handling-guidelines.html
To submit feature request please provide information on the usage scenario, feature requirements and expected implementation timeline for the feature. This information will help Open CAS community to plan feature implementation.
All contributions are welcome! Don’t hesitate to submit a pull request! Patch submission requirements:
- Contributions are accepted on BSD-3-Clause license.
- All patches must be
signedoffby the developer, which indicates that submitter agrees to the Developer Certificate of Origin (DCO).
- Commits must conform to Open CAS coding standard which is based on Linux kernel coding standard (coding style).
- Commits should build and pass tests.
- Commits should contain a clear message describing purpose of the commit (e.g. bug fix, improvement, etc.). Ideal commit description should provide information on why change is needed (e.g. what problem is being solved) and how this change solves the problem.
Example commit with title, description and signoff information:
commit 6598b61a478d44c26e3147baec6ce002a4c77fa8 (HEAD -> contributions) Author: John Doe <john.doe@example_org.com> Date: Thu Jan 17 22:06:10 2019 -0700 Example change fixing SW problem This change fixes a SW crash occurring when software is used in scenario A, B and C. That crash impacts user data availability. This commit fixes this problem by introducing following changes. Signed-off-by: John Doe <john.doe@example_org.com>
Code review is performed using the Github’s default review tool. 2 approves are required for the pull request to be merged into main branch.
Typical flow for introducing changes
Usually development starts with cloning and checking out recent ‘master’ branch, where you will start introducing your changes. To create a new local branch named ‘my_changes’, based off ‘origin/master’ branch run following command.
git checkout -b my_changes origin/master
Introduce changes to desired files and commit changes to the local repository. Edit commit title and description. Common practices to maintain good commit description is to adhere to following rules:
- Separate commit title from description.
- Commit title message should be short (less than 50 characters) and should summarize the change. Start title with capital letter, do not end with a period.
- Longer commit description should come after title and should be separated with single a blank line. Message should wrap at 72 characters and provide description for the change explaining what, why, how.
- Make sure that your name and email address for author and signoff sections are correct.
# Stage files for commit git add example_file.txt # Commit files locally git commit --signoff
Finally push branch containing changes to the remote repository and open new pull request on the github.
git push my_changes origin
Naming conventions in the documentation
The product name
- Open CAS Linux
The write policies
The cleaning policies abbreviations
The sequential cutoff policies
The promotion policies
- cache device
- exported object == cache volume
- core device == backend device
- IO class
- sequential cutoff
- promotion policy
- cache line
- IO request
Maintainers primary responsibility is to provide technical guidance on contributions, perform code review and oversight of project direction. The primary contact: