This patch list and descript typical openEuler kernel header format.
Signed-off-by: Zheng Zengkai zhengzengkai@huawei.com --- openeuler_patch_header.lg | 178 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 178 insertions(+) create mode 100644 openeuler_patch_header.lg
diff --git a/openeuler_patch_header.lg b/openeuler_patch_header.lg new file mode 100644 index 000000000000..a874d140cd1c --- /dev/null +++ b/openeuler_patch_header.lg @@ -0,0 +1,178 @@ +Patch format definition + +[M] stands for “mandatory” +[O] stands for “option” +$category can be: bug preparation, bugfix, perf, feature, doc, other… + +If category is feature, then we also need to add feature name like below: +category: feature +feature: YYY (the feature name) + +If the patch is related to gitee issue, then we need add the corresponding tag +like below. +for example: +bugzilla: https://gitee.com/openeuler/kernel/issues/I4OM1C + +Additional changelog should include at least one of the flollwing: +1) Why we should apply this patch +2) What real problem in product does this patch resolved +3) How could we reproduce this bug or how to test +4) Other useful information for help to understand this patch or problem + +The detail information is very useful for porting patch to another kenrel +branch. + +stable patch header format: + +origin patch title + +stable inclusion [M] +from $stable-version [M] +commit $id [M] +category: $category [M] +bugzilla: $gitee-issue-url [M] +CVE: $cve-id or NA [O] + +Reference: patch URLs + +additional changelog [O] + +------------------------------------------ + +original changelog + +Signed-off-by: $author $name@huawei.com [M] + +($stable-version would be stable-4.19.110, stable-4.19.111, etc… +$id would be stable commit) + +mainline patch header format: + +origin patch title + +mainline inclusion [M] +from $mainline-version [M] +commit $id [M] +category: $category [M] +bugzilla: $gitee-issue-url [M] +CVE: $cve-id or NA [M] + +Reference: patch URLs + +additional changelog [O] + +------------------------------------------- + +original changelog + +Signed-off-by: $author $name@huawei.com [M] + +($mainline-version could be mainline-5.5, mainline-5.6, etc…) + +HULK patch header format: + +origin patch title + +hulk inclusion [M] +category: $category [M] +bugzilla: $gitee-issue-url [M] +CVE: $cve-id or NA [M] + +------------------------------------------ + +changelog + +Signed-off-by: $author $name@huawei.com [M] + +distribution patch header format: + +origin patch title + +dist inclusion [M] +from $dist-version [M] +commit $id [O] +category: $category [O] +bugzilla: $gitee-issue-url [O] + +additional changelog [O] + +----------------------------------------- + +original changelog + +Signed-off-by: $author $name@huawei.com [M] + +($dist-version could be centos-7.5, centos-7.7, etc…) + +EulerOS patch header format: + +origin patch title + +euleros inclusion [M] +category: $category [M] +bugzilla: $gitee-issue-url [O] + +---------------------------------------- + +changelog + +Signed-off-by: $author $name@huawei.com [M] + +Driver patch header format: + +origin patch title + +driver inclusion [M] +category: $category [M] +bugzilla: $gitee-issue-url [O] + +additional changelog [O] + +--------------------------------------- + +original changelog + +Signed-off-by: $author $name@huawei.com [M] + +======== + +Examples + +mm: introduce memmap_alloc() to unify memory map allocation + +mainline inclusion +from mainline-v5.15-rc1 +commit c803b3c8b3b70f306ee6300bf8acdd70ffd1441a +category: bugfix +bugzilla: 186414, https://gitee.com/openeuler/kernel/issues/I5K7IY +CVE: NA + +Reference: +https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i... + +-------------------------------- + +There are several places that allocate memory for the memory map: +alloc_node_mem_map() for FLATMEM, sparse_buffer_init() and +__populate_section_memmap() for SPARSEMEM. + +The memory allocated in the FLATMEM case is zeroed and it is never +poisoned, regardless of CONFIG_PAGE_POISON setting. + +The memory allocated in the SPARSEMEM cases is not zeroed and it is +implicitly poisoned inside memblock if CONFIG_PAGE_POISON is set. + +Introduce memmap_alloc() wrapper for memblock allocators that will be used +for both FLATMEM and SPARSEMEM cases and will makei memory map zeroing and +poisoning consistent for different memory models. + +Link: https://lkml.kernel.org/r/20210714123739.16493-4-rppt@kernel.org +Signed-off-by: Mike Rapoport rppt@linux.ibm.com +Cc: Michal Simek monstr@monstr.eu +Signed-off-by: Andrew Morton akpm@linux-foundation.org +Signed-off-by: Linus Torvalds torvalds@linux-foundation.org +Conflicts: + mm/page_alloc.c +Signed-off-by: Liu Shixin liushixin2@huawei.com +Reviewed-by: Kefeng Wang wangkefeng.wang@huawei.com +Signed-off-by: Zheng Zengkai zhengzengkai@huawei.com