Skip to content

Latest commit

 

History

History
152 lines (93 loc) · 3.93 KB

2.First-patch.rst

File metadata and controls

152 lines (93 loc) · 3.93 KB
Raw

First Patch

This includes steps to getting your first patch merged into the mainline kernel.

NOTE: Do not submit patches to any part of the kernel outside of drivers/staging whilst getting started with kernel development.

Pro Tip: Limit scope to the following directories;

  • Documentation/process/
  • drivers/staging/
  • include/linux/
  • include/uapi/

1. Tools

Set up your tools

  • Editor: The kernel uses a specific coding style, you may like to configure your editor to support this.
  • Email: All kernel development is done in the open, this means via mailing lists. All patches are sent inline, this means no attachments.
  • Git: Configure git with your email address and name. All kernel changes must contain a tag
Signed-off-by: Joe Developer <[email protected]>

You may wish to add to your git config

[format]
        signOff = true

You may also need

[user]
        email = [email protected]
        name = Joe Developer

Pro Tip: If you already have git configured with your GitHub username then add the real name configuration lines to the git config file within your kernel development tree (see task 3 below).

2. Mailing Lists

Subscribe to the following mailing lists

Pro Tip: Do not bother subscribing to LKML at this stage.

At this stage you may like to sort emails from mailing lists into separate mail boxes. Example regex for sorting;

^List-ID:.*<driverdev-devel.linuxdriverproject.org>$

Pro Tip: Always maintain the complete CC list when responding to mails on a kernel mailing list.

3. Tree

Set up development tree.

Pro Tip: Work off of staging-next but make sure your patches apply to staging-testing before you submit them to the driver dev mailing list.

4. Checkpatch

Run checkpatch.pl against drivers in staging until you find a warning that you feel you can fix.

scripts/checkpatch.pl -f drivers/staging/FOO/*.c

Pro Tip: Do not fix line over 80 warnings.

5. Code

Fix all instances of the warning within the driver you have chosen. While not essential, if a job is worth doing it is worth doing properly.

6. Commit

Commit your changes as a single commit. Write a correct git log for the commit. Read

Documentation/process/submitting-patches.rst

Commit log messages must be of a specific format and content. At first they are difficult and time consuming to write. You may even find you spend more time writing git logs at first than code. Keep at it, you will learn a lot from doing it thoroughly. If you want to be taken seriously you need to apply effort to learning the development process and display that you have done so.

7. Submit

Create and send patch using git

git format-patch HEAD~
git send-email --to='Joe Developer <[email protected]>' 0001-xxx-xxx.patch

Check the TODO file for whom to send the patch to, or use

scripts/get_maintainer.pl

8. Respond

Respond to feedback you receive from maintainers and/or reviewers.

If asked to do so, fix your patch and re-submit.

Pro Tip: Wait at least two weeks before following up on any email sent to a kernel mailing list.

Final

At this stage, if all went successfully, you should get an email from Greg Kroah-Hartman saying that your patch was merged into staging-testing. From here your patch will automatically transition to staging-next then, when the next merge window opens, will by merged into Linus' mainline.