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:
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:
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.
Linux Embedded systems Related Tutorials
Linux Embedded systems Related Interview Questions
|Linux Embedded systems Interview Questions||Red Hat Linux Essentials Interview Questions|
|Red Hat Linux System Administration Interview Questions||Ubuntu Certified Professional Interview Questions|
|IBM AIX Interview Questions||Solaris Interview Questions|
|HP-ux 11iv3 system administration Interview Questions||Red Hat cluster Interview Questions|
|Embedded C Interview Questions||Unix/Linux Interview Questions|
|Unix Shell Scripting Interview Questions||Solaris Administrator Interview Questions|
Linux Embedded systems Related Practice Tests
|Linux Embedded systems Practice Tests||Red Hat Linux Essentials Practice Tests|
|Red Hat Linux System Administration Practice Tests||Ubuntu Certified Professional Practice Tests|
|IBM AIX Practice Tests||Solaris Practice Tests|
|HP-ux 11iv3 system administration Practice Tests|
Linux Embedded Systems Tutorial
About Embedded Linux
Configuring The Software Environment
Target Emulation And Virtual Machines
Starting Your Project
Getting Linux For Your Board
Creating A Linux Distribution From Scratch
Booting The Board
Configuring The Application Development Environment
Kernel Configuration And Development
Using Open Source Software Projects
Handling Field Updates
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.