- Lustre code that best encompasses the change being made. Examples of
- components include modules like: llite, lov, lmv, osc, mdc, ldlm, lnet,
- ptlrpc, mds, oss, osd, ldiskfs, libcfs, socklnd, o2iblnd; functional
- subsystems like: recovery, quota, grant; and auxilliary areas like:
- build, tests, docs. This list is not exhaustive, but is a guideline.
-
- The commit comment should contain a detailed explanation of the change
- being made. This can be as long as you'd like. Please give details
- of what problem was solved (including error messages or problems that
- were seen), a good high-level description of how it was solved, and
- which parts of the code were changed (including important functions
- that were changed, if this is useful to understand the patch, and
- for easier searching). Wrap lines at/under $WIDTH_REG columns.
-
- Finish the comment with a blank line and a blank-line-free
- sign off section:
+ Lustre code best covering the patch. Example components include:
+ llite, lov, lmv, osc, mdc, ldlm, lnet, ptlrpc, mds, oss, osd,
+ ldiskfs, libcfs, socklnd, o2iblnd; recovery, quota, grant;
+ build, tests, docs. This list is not exhaustive, but a guideline.
+
+ The comment body should explan the change being made. This can be
+ as long as needed. Please include details of the problem that was
+ solved (including error messages that were seen), a good high-level
+ description of how it was solved, and which parts of the code were
+ changed (including important functions that were changed, if this is
+ useful to understand the patch, and for easier searching).
+ Performance patches should quanify the improvements being seen.
+ Wrap lines at/under $WIDTH_REG columns.
+
+ Finish the comment with a blank line followed by the signoff section: