Open Source Community - Linux Embedded systems

The kernel, like other open source projects, is open to contributions from its users. In addition, the kernel is a highly distributed project, in a geographical sense, with users from all over the world contributing on a regular basis. These contributions are made when a developer makes changes to the code and submits a patch with those changes so they can be included in the mainline kernel project.

This presents the following questions:

  • How do you create a patch?
  • To whom do you send the patch?
  • What happens after you submit a patch?

This section covers these three questions. Most users don’t submit kernel patches, just like most Wikipedia readers don’t change content; but knowing how the process works is still valuable and helps make sense out of applying patches, as also covered in this section.

The Kernel Development Process
The kernel project uses a rolling integration process. This means software checked into project should work and build without error. For a project as big as Linux, this is more that can be done by one person.

So, for each major subsystem in the kernel, there is a maintainer who is responsible for reviewing patches. The subsystem maintainers have to ensure that subsystems work, meet the kernel code standards, and build correctly. You can find the canonical list of maintainers in the MAINTAINERS file in the root of the Linux kernel. The maintainers keep a queue of patches at the ready, until Linus Torvalds, the top-level maintainer, sends an e-mail to the maintainers requesting changes, opening what is referred to as the merge window.

The maintainers send their queued changes to Linus, who merges them with the source from the prior release. This process continues for several weeks until the merge window is considered closed.

After it’s closed, the only changes that are accepted are those that fix defects in the newly accepted code or other major defects. These versions of the Linux kernel are called rc<serial number>, where serial number starts at one and increments upward for every release. A new bug-fix release happens about once a week.

When Linus finds that the code is stable enough with “stable” meaning that the regression tests are passing and the maintainers working on the kernel agree Linus issues a new kernel release, and the cycle starts again.

Contributing to the Linux Kernel
Contributions, big and small, are welcome. Many developers who make small changes to the kernel don’t bother contributing their changes, because they view them as not important. If you’ve made a change that fixes a problem, makes the kernel more stable, or adds a new feature, it will be welcomed by the open source community.

You submit code to maintainers in the form of a patch. Patches show the differences between two files; in order for patches to work, both you and the recipient of the patch need to agree on the basis for the patch. In Linux, patches are made against the latest stable version of the Linux kernel.

To submit a patch, follow these steps:

  1. Fetch a copy of the kernel sources. Getting the Linux sources was described earlier; the same instructions apply for this use case.
  2. Unpack that kernel next to your kernel code. For example, say your Linux source tree is stored at ~/my-linux. You want to unpack the newly downloaded kernel so that my-linux and it share the same parent directory.
    The Linux kernel is constructed so that if you do the following, things will be correctly positioned for the next step:
  3. Use diff to create a patch. Before you create a patch, the kernel must be in clean state, because the patch process finds all the differences between the two source trees. The distclean target does exactly that, removing output file and even editor backup files. Because your code and the kernel’s source tree are in the same directory, creating a patch is easy:
    This command produces a unified diff containing all the changes between the your-kernel-tree and kernel-sources.
  4. Check the patch. In order to make the life of the person who will be reviewing your patch easier, the kernel has a script that scans a patch file and returns common errors. This is likely the first thing the maintainer will check; they will reject your patch if this program returns errors:
  5. Find the maintainer, and send e-mail. Look in the MAINTAINERS file for an entry that matches the part of the kernel where you made the change. Say the changes have to do with the Atmel board; you’ll find an entry that looks like the following
    P: Andrew Victor
    L: (subscribers-only)
    S: Maintained This means the maintainer is Andrew Victor (P), and you can send your patch to the address in field M. Include your patch in the e-mail as text, not as an attachment. Maintainers prefer plain-text e-mail. Many e-mail program use HTML to mark up pages with fonts, indents, pictures, and the like. All this layout information is a distraction to a user who is likely using a text-only e-mail reader in a terminal window where HTML mail messages appear to be a series of attachments.
  6. Watch for follow-ups. Your patch is likely to be returned to be improved on further. The maintainer may have questions, the code may have formatting problems not discovered by, it may not work on their machine, and so on. If the maintainer lets you know there’s a problem, fix it, test it, and resend the patch. Will your patch get rejected? Nobody likes rejection. The answer is, “Maybe.” Patches are rejected when the maintainer gets several patches that solve the same problem and must select one. Patches are also rejected because they don’t solve the problem in a way that the maintainer believes is the best way for the project or when the solution causes regressions or other problems. A maintainer will tell you why your patch wasn’t accepted and frequently offer you advice on how to improve it.

Applying Patches
Applying a patch means using a program that takes a patch file and makes changes to your source tree as instructed by the patch. The patch file, as explained in the prior section, is nothing more than a diff between your source tree and the prior latest stable version of the kernel. You apply a patch using the patch program like so:

-p1 means to ignore the first directory of a patch file. Recall that when the patch was created, it was made by comparing two directories. By dropping the first directory in the patch specification, you’re running it relative to your current directory. For example, if the patch was made to the main/init.c program, the patch would contain instructions that some-directory/main/init.c required a change.

When you run patch from the root of the kernel source tree, you’re currently in the same directory as some-directory; removing that one directory from the specification instructs patch to update the file main/init.c.

Patch doesn’t perform atomic updates, in that if there are three changes in three different files, it makes as many changes as possible; patches that don’t apply result in error messages, and files that can’t be changed are left in their present condition. When you’re applying a patch, you can test if it will be successfully applied by doing the following:
$patch -p1 --dry-run < /path/to/patch.file

When you’re applying several patch files, the order can be important, because a patch that’s making a change in a file may depend on a prior patch being run. When you receive a group of patches, it’s critical that you also receive information about the ordering. Many times, patches can be applied in any order, but this isn’t always the case; determining the correct order through examination (or experimentation) is impractical.

All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd Protection Status

Linux Embedded systems Topics