最近因为工作需要，要上传代码到 DPDK 上，代码已经上传成功，记录一下过程，给大家提供一个参考。我这次需要上传的是pmd，即poll mode driver。

1 Coding Style

要上传代码，第一件事就是需要知道Coding Style。当然，在写完代码后，通过格式调整工具进行调整也是可以的，但是如果我们养成了良好的代码习惯，那将节省掉很多不必要的工作量，这在我的第一次上传经历中体现的尤为明显。代码本身因为我本次测试过很多遍，所以不会有太多改动，格式问题是一个重要的修改方向。

DPDK的Coding Style在之前的文章中有提到，它基本和Linux Kernel的是一致的，这里我单独拿出一些来讲，需要看详细的可以参考我的文章。

DPDK Coding Style文章浏览阅读182次。最近看了一下 DPDK Coding Style，做了一下总结，分享一下。https://blog.csdn.net/weixin_39950873/article/details/1315347541、行长最好不要超过80个字符，注释也是一样。

2、Tab应该是八个字符宽

3、注释最好不要使用 //

4 、缩进的话最好使用tab，如果多个tab无法做到，比如只差7个字符，那就用七个空格。而空格一般是用来对齐的。具体如下：

unsigned long really_long_proc_name(unsigned long x, unsigned long y,int a)
|------||-------||------||-------|__t        t       t       t     ss
{p1 = first_procedure (second_procedure (p2, p3),third_procedure (p4, p5));
|------||------||------|______t       t       t    ssssss
}

5 、if else需要对称，比如if只有一条语句，而else有多条，那你不能if就不用大括号了，而else用。当然，如果if和else都只有一条语句，那记得不要用大括号。

CHECK:BRACES: braces {} should be used on all arms of this statement (from ./checkpatch.pl)
#268: FILE: drivers/net/r8169/r8169_hw.c:67:
if (len <= 4 - val_shift)stmt;
else {

然后呢，我给大家推荐两个工具。第一是checkpatch.pl。它是Linux Kernel自带的，它不光检查代码格式，也会检查你的patch的其他内容，一般都需要先执行一遍才行。一句示例命令如下：

./scripts/checkpatch.pl --no-tree --ignore=CAMELCASE xxx.patch

第二个是老朋友了，即astyle。它可以帮助我们调整代码格式，至于option可以自行根据需要选择。但是他在对缩进方面存在一些问题，做不到我上述第四点的情况。也是提供给大家做一个参考。

自动调整代码格式——astyle详解https://blog.csdn.net/weixin_39950873/article/details/131635456

2 了解你要上传的项目

比如你要上传到Linux，那你一定要去了解它怎么上传，上传到哪里等等一系列的内容，不然就会像没头苍蝇一样乱撞。我这里以DPDK为例。

2.1 DPDK 开发流程

- 代码托管在公共 git 存储库中。
- 有一个邮件列表，开发人员可从中提交补丁。
- 有分层组件的维护者。
- 补丁在邮件列表中公开审核。
- 成功审核的补丁将合并到存储库。
- 补丁应发送至目标存储库或子树，见下文。

DPDK 开发的邮件列表是 dev@dpdk.org。贡献者需要注册邮件列表才能提交补丁。

2.2 源代码许可

DPDK 对核心库和驱动程序使用开源 BSD-3-Clause 许可。内核组件采用 GPL-2.0 许可。DPDK 在源文件中使用 Linux 基金会 SPDX 项目定义的单行唯一许可证标识符引用。

2.3 Maintainers and Sub-trees

DPDK 维护层次分为主存储库 dpdk 和子存储库 dpdk-next-*。比如我这次要上传的pmd，它的子储存库就是dpdk-next-net，那么在git clone的时候，就得git clode它才行，不能搞错了。

其次呢，我要上传pmd，并不是一个修改的patch，所以作为maintainer，我需要在MAINTAINERS文件里更新我的信息。

2.4 里程碑

DPDK每年的小版本有三个，分别在三月七月和十一月更新版本。每次更新都会有rc1 ~ rc4这个阶段，不同阶段的工作如下，所以我们应该在此之前上传对应的patch，当然，早一点总比晚一点强。

rc1：优先级：库。-rc1 之后不应接受任何库功能。

rc2：优先级：驱动程序。-rc2 之后不应接受任何驱动程序功能。

rc3：优先级：应用程序。-rc3 之后不应接受任何应用程序功能。

rc4：文档更新。

3 Git

在Linux上上传代码，用Git十分常见，这里也做一些介绍。

3.1 获取源码

我们需要把源码通过 git clone 克隆到本地然后再做进一步的操作。如上文所说，你得知道你应该git clone的代码是什么。DPDK有主仓库和子仓库如下：

main repository:

git clone git://dpdk.org/dpdk

git clone https://dpdk.org/git/dpdk

sub-repositories (list):

git clone git://dpdk.org/next/dpdk-next-*

git clone https://dpdk.org/git/next/dpdk-next-*

这里我们要git clone的就是子仓库dpdk-next-net，在修改前就应该搞明白，不要走冤枉路。

3.2 Commit Message

3.2.1 主题行

git 提交消息的第一行（摘要）将成为补丁电子邮件的主题行。

- 摘要行必须捕捉变更的区域和影响。
- 摘要行应约为 50 个字符。
- 除首字母缩略词外，摘要行应小写。
- 它应以组件名称作为前缀（使用 git log 检查现有组件）。
- 使用动词的命令式（如对代码库的说明）。
- 不要在主题中添加句号。

比如：net/r8169: add PMD driver skeleton

3.2.2 主体

- 消息正文应描述正在修复的问题或正在添加的功能
- 当更改显而易见时，除签名外，正文可以为空白。
- 提交消息必须以 Signed-off-by: 行结尾，该行使用以下命令添加：
git commit --signoff # 或 –s
- 签名必须是真实姓名，而不是别名或昵称。允许多个签名。
- 提交消息的文本应在 72 个字符内换行。

3.3 生成和检查 patch

可以直接从 git 发送补丁，但对于新贡献者，建议使用 git format-patch 生成补丁，然后当一切正常并且补丁已经过检查时，使用 git send-email 发送它们。

# Generate a patch from the last 3 commits.
git format-patch -3
# Add a prefix with a version number.
git format-patch -3 -v 2
# check these patches
./scripts/checkpatch.pl --no-tree xxx.patch

一些基本的诸如 git add . 和 git commit命令就不做赘述了，这里我们着重介绍一下git rebase。我本人对这个命令的应用也仅限于个人使用到的场景，并没有那么精通，不过抛砖引玉，和大家分享一下倒是无所谓。

比如你的仓库下有四个提交，然后你想修改第一个提交。你可以用下面的命令，然后得到下面的界面。

git rebase -i HEAD~4

pick   commitID_1   commit log 1

pick   commitID_2   commit log 2

pick   commitID_3   commit log 3

pick   commitID_4   commit log 4

第二步，将第一个pick修改为edit，然后退出。这样你就到了commit 1，你可以做修改，然后正常 git add，注意git commit要加上--amend，然后你需要执行

git rebase –continue

这样，如果没有冲突的话，那就完成了。

但是有时候不会这么顺利，那么就需要打开冲突的文件然后fix。在fix后，先git add，然后记得不要做git commit，直接继续执行git rebase --continue。如下图所示，图1是修改前，图2是遇到冲突了。

这里为什么强调不要做git commit呢？因为我因此丢了一个commit。原理其实很简单，你第一次git rebase，然后做git commit --amend，这是在修改最近的一次提交，然后git rebase --continue。但是，在你发生冲突的时候，它其实是需要解决冲突然后继续rebase的，并不是要去修改最近的一次提交。也许有些绕口，这理解也有很多个人的理解，如果我的描述有问题，也欢迎交流。所以这时候，你如果使用了git commit，你就会把两个commit合成一个，也就会丢掉一个commit。如下图所示。

这时候我们该怎么做呢？如果我们没有做rebase，那么可以先把BC'的内容换成B'然后继续git amend后git rebase。这样就会变成只少了一个C'。然后呢，我们继续git rebase，切换到B'后，git add并git commit C'，把它加入，之后git rebase即可。如下图，

但是如果不巧，你已经rebase完成了，那么就需要再次rebase，先切到BC'，然后先git commit --amend，把B'改好，然后再git add并git commit C'，之后git rebase。

3.4 发送patch

首先需要编辑.gitconfig。主要是name、email、serverport、server等。

然后就可以发送patch了，这时候如果生成了patch，那么就可以

git send-email --to xxx A.patch B.patch C.patch

如果没有生成patch就可以通过下面的命令，这样一下子就可以发送最近的三个patch上去，当然，最好加上封面信的option。

git send-email --to xxx -3 --cover-letter --annotate --subject-prefix 'PATCH v1'

至此，patch就已经发送出去了。

3.5 修改patch

patch发送出去后，maintainer会提供修改意见给你，然后你们可以通过邮件交流，在通过上述的步骤一次又一次修改和上传后，你的代码就会被merge进去。

4 总结语

这次上传经历也是我作为maintainer的开始，记录一下这个过程与大家分享。

如果觉得这篇文章有用的话，可以点赞、评论或者收藏，万分感谢，goodbye~