写在前面
其实在写提交补丁之前，需要开篇大概讲一下开源社区运作模式和流程，并讲下在开源社区如何参与讨论以及一些注意事项，但是因为内容限制，这里无法展开讲述。但既然提交补丁已经涉及到与其他参与者交流，我还是大概讲下提交补丁需要注意的事情：
- 提交补丁之前请仔细检查补丁，并通过checkpatch.pl工具仔细检查（后面会提到这个工具），确保提交上去的正确性（毕竟邮件发送完毕后无法撤回）；
- 在提问或者提交相关补丁之前，一定要先查阅相关资料，保证自己对这块已经吃透，提问或者提交的补丁确实算是“问题”（至少自己看来是问题）。主要避免自己什么都不懂张口就问，然后发现是一些低级问题。
- 请遵从LTP提交补丁规则习惯。比如标题一般 [LTP][PATCH xx] 主题，其实这个很简单，订阅邮件列表后先看看别人怎么提交的。
- 有好的idea，尽量以代码方式体现，言语是苍白的（”show me the code”）。
- 讨论问题尽量有根有据，礼貌客气，大家欢快讨论。千万不要争论，有意见可以适当辩论，必须带有依据（证据），更不能辱骂（全世界参与者都在看着哈）。
嗯，如果还是怕出问题，那么还是多看看邮件列表其他人的邮件交流方式吧。
补丁提交方式
1.先自己造个bugfix，以testcases/kernel/syscalls/open/open01.c为例
static void setup(void)
{
SAFE_MKDIR(TEST_DIR, 0755);
}
static void cleanup(void)
{
if (fd > 0)
SAFE_CLOSE(fd);
}setup()通过mkdir(TEST_DIR)创建了TEST_DIR，那么cleanup()需要rmdir(TEST_DIR) （哎呀，没准真是问题呢）。
2.进行修改，添加SAFE_RMDIR()删除目录
static void cleanup(void)
{
if (fd > 0)
SAFE_CLOSE(fd);
SAFE_RMDIR(NULL, TEST_DIR);
}3.提交commit
1) git branch 查看保证在master分支，如果不在执行 git checkout master
2) git add testcases/kernel/syscalls/open/open01.c
3) git commit
这里会填写commit信息，格式如下
bugfix for open/open01.c
Add SAFE_RMDIR(NULL, TEST_DIR) to cleanup TEST_DIR.
Signed-off-by: Bixuan Cui <[email protected]>
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Your branch is up-to-date with 'origin/master'.
#
# Changes to be committed:
# modified: testcases/kernel/syscalls/open/open01.c第一行是commit标题，简练的说明这个commit是干什么的；
第三行是commit内容，标题与内容隔开一行，然后讲述这个commit作用，可以按照之前错误是什么现象、个人对其问题分析、commit作用以及最终效果（因为这个比较简单，所以一句话说明，不要担心表述不清楚，因为maintainer看一行你代码，估计都不需要你说什么就知道你要干什么了）
第五行是commit的作者声明，与内容隔开一行，一般放在最后面，就是自己姓名和邮箱啦（一定要带哦，出了问题找你^_^）。
4）保存后可以使用git commit –amend继续修改哦。
5）git format-patch -1 -o .
生成patch，-1表示最近的一个commit，-o指定生成目录。最终生成0001-bugfix-for-open-open01.c.patch
6）对patch进行修改：
a.
Subject: [PATCH] bugfix for open/open01.c
改成
Subject: [LTP][PATCH] syscalls/open: bugfix for open/open01.c
说明，这两块必须体现，[LTP]表示LTP社区，syscalls/open表示对syscalls的open下面的修改。
b. 如果是自己第二版的修改了，请改成
Subject: [LTP][PATCH v2] syscalls/open: bugfix for open/open01.c
并且
Signed-off-by: Bixuan Cui <[email protected]>
---
这里添加(v2->v1: 修改内容)
testcases/kernel/syscalls/open/open01.c | 2 ++
1 file changed, 2 insertions(+)c. 如果2个相连的commit（其实初学者估计不会写到多个commit，因为一般是提交用例或者大改时候，那时候你已经不用看这篇文章了），那么git format-patch -2 -o . 或者手动修改 [PATCH v1] [PATCH v2]
7）使用linux的checkpatch.pl检查patch：
请先git下载linux任意版本（既然学ltp，linux代码也得学呀）
../linux/scripts/checkpatch.pl -f 0001-bugfix-for-open-open01.c.patch
ERROR: trailing whitespace
#24: FILE: 0001-bugfix-for-open-open01.c.patch:24:
+ $
ERROR: trailing whitespace
#26: FILE: 0001-bugfix-for-open-open01.c.patch:26:
+-- $
total: 2 errors, 0 warnings, 28 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
NOTE: Whitespace errors detected.
You may wish to use scripts/cleanpatch or scripts/cleanfile
0001-bugfix-for-open-open01.c.patch has style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.嗯，patch的第24和26行，多了$，其实就是空格，vim打开patch，把多出的空格删除，一定要保证-f检查不报错。就像这样
../linux/scripts/checkpatch.pl -f 0001-bugfix-for-open-open01.c.patch
total: 0 errors, 0 warnings, 28 lines checked
0001-bugfix-for-open-open01.c.patch has no obvious style problems and is ready for submission.8）再整体check一遍patch，仔仔细细滴；
9）发送邮件到邮件列表
git send-email –to [email protected] 0001-bugfix-for-open-open01.c.patch
至此，可以看下ltp邮件列表有没有自己邮件啦，一般两三天会有回复的。
如何快速发现LTP中bug（为了学习提交补丁和社区交流）
个人总结的很容易发现的bug，提交补丁的点：
1.下载最新linux发布版本执行ltp测试
个人可以安装个虚拟机，然后替换到最新内核，执行ltp测试。因为linux接口变更或者特性修改，ltp无法及时更新（其实ltp对内核新特性和接口更改的维护一直都是参与者来补充的），这时候会发现新的TFAIL或者TBROK用例，结合linux修改仔细分析下就能发现问题。
2.在不同架构下执行LTP
LTP的版本，更多的保证X86平台，对于其他架构也提供兼容性，但是真正去测试使用的很少。个人很多的patch都是修复ltp部分用例对arm(arm64)平台兼容性不够的问题，最近比较火的RISC-V linux逐渐提供支持，ltp也要跟上的，这个平台估计会有问题。
3.自己提交用例
个人时常关注下linux社区的changelog，还有lwn社区的最新信息，收集linux的接口变更和新增特性，对这些功能新增用例，很容易被接收的（个人层提交过xattr特性的用例代码）。
4.其他
对ltp框架执行感觉麻烦的地方，可以进行优化。
个人建议还是先从bugfix提交开始。
