It took me a couple months to get back to my patch, and in the interim, I forgot everything about formatting a patch series to LKML. Here’s what I have remembered.

Older Versions

Typically, I am responding to code review comments. I need to look at the code I am actually submitting, and make sure I have addressed all of the comments. Typically, I need to look at the older version of the code when I do this. I keep the older version in one branch, and the newer version in another. Then, I can compare the versions using:

git diff oldbranch newbranch -- filename

For example

git diff  mctp-over-pcc-v30  admiyo/mctp-net-next  --  drivers/net/mctp/mctp

In the future I think I will actually create a new branch with all of the code review comments in it, so I can diff the new code against the comments.

Tools

There are a handful of tools I need to run to check my code before submitting a patch to the Linux Kernel.

Compiler Checks

As always, the compiler is your first line of defense. Build your code with W=1, if only your specific .o files, to ensure that you are not suffering from code issues. Variables that are assigned but never used are a common one. If I have one:

 make  W=1 drivers/net/mctp/mctp-pcc.o
  CALL    scripts/checksyscalls.sh
  DESCEND bpf/resolve_btfids
  INSTALL libsubcmd_headers
  CC [M]  drivers/net/mctp/mctp-pcc.o
drivers/net/mctp/mctp-pcc.c: In function ‘mctp_pcc_rx_alloc’:
drivers/net/mctp/mctp-pcc.c:71:16: error: variable ‘v’ set but not used [-Werror=unused-but-set-variable]
   71 |         void * v;
      |                ^

This couples with enabling CONFIG_WERROR=y in the config catches some significant problems.

Checking for endianess issues using a W=1 build. Typically I will do this via

make W=1 drivers/net/mctp/mctp-pcc.ko

Patch Format Checker

Next is the standard format checker included in the kernel itself. I run it this way:

./scripts/checkpatch.pl –max-line-length=80 <file>

It can also be run on a patch, but since my patch is pretty much a file, I used to run it against the file. However, passing in the patch file also works, and will check the commit message.

Reverse Xmastree Format

For Networking code there is an additional requirement, reverse xmas tree order – longest line to shortest – for local variable declarations.

This tool checks that format: https://github.com/ecree-solarflare/xmastree

kernel doc

Some functions have formatted comments preceding them that are used to generate automated documentation for the code. These are called Kernel Docs. If you are creating or modifying any kernel docs, run the script to ensure they are properly formatted, like this:

./scripts/kernel-doc -Wall -none drivers/mailbox/pcc.c

Patch formatting

The cover letter goes in the branch description

git branch --edit-description

When preparing the patches, generate them using git format-patch like this:

git format-patch  --cover-from-description=subject   -2 -v6 --cover-letter 

This produces:

v6-0000-cover-letter.patch
v6-0001-mctp-pcc-Check-before-sending-MCTP-PCC-response-A.patch
v6-0002-mctp-pcc-Implement-MCTP-over-PCC-Transport.patch

If you don’t add –cover-from-description=subject then the cover letter needs to be edited,as it has a line like this in it:

Subject: [PATCH v6 0/3] *** SUBJECT HERE ***

Instead, use the switch to make the first line of the description suitable for your Subject.

.gitconfig

Instead of adding all of the commands to git send-email, I have added them to ~/.gitconfig

[user]
	email = admiyo@os.amperecomputing.com
	name = Adam Young
[core]
	editor = /usr/bin/vi
[init]
	defaultBranch = main
[sendemail]
smtpserver = /usr/bin/msmtp
confirm = auto
confirm = always
smtpserveroption = -v
from = admiyo@os.amperecomputing.com
 
[sendemail.mctp]
    sender = Adam Young
    #cccmd ="`pwd`/scripts/get_maintainer.pl --nogit --nogit-fallback --norolestats --nol"
    tocmd ="`pwd`/scripts/get_maintainer.pl --nogit --nogit-fallback --norolestats --nol"

I have also added a bunch of people to the cc = section manually that are interested in the patch but not automatically notified. I will have to remove this when I change to working on a different patch.

dry run

Before I send the patch:

 git  send-email  --cover-letter *patch --dry-run  --identity=mctp