Posts

The Real-Time Linux project team continues to prepare the remaining patches for inclusion into the mainline kernel.

Long ago in 2009, a small team of kernel developers had finished consolidating previous  prototypic developments to make Linux real-time capable into a single out-of-tree patch set, called the PREEMPT_RT patch set. This patch set can be applied to turn a vanilla mainline Linux kernel without real-time capabilities into a real-time capable Linux kernel. Many companies use this patch set to build various industrial systems that required to implement hard real-time properties at comparatively relaxed time bounds of about one millisecond precision.

BMW Car IT also used this patch set to build real-time capable prototypes for complex functions in the area of autonomous driving. However, from the beginning with the development of those prototypes, it was clear that any product with high-quality demands requires to get the PREEMPT_RT patch set in the main-line development for increased compatibility of features, stronger quality assurance and reduced maintenance. Hence, BMW Car IT started driving efforts to make Linux real-time capable in 2014.

First, BMW Car IT joined OSADL, the Open Source Automation Development Lab, as a Gold member to support real-time Linux development activities, which was collaboratively funded by the OSADL member at that time.

Second, our former colleague Daniel Wagner started to get acquainted with the existing PREEMPT_RT patch in 2014 and made a number of contributions to the Linux kernel related to real-time capabilities from 2015 until end of 2016. Due to his experience with the PREEMPT_RT patch, he is now the maintainer of the Linux 4.4 real-time stable branch, and one of the three maintainers for the real-time stable patch branches.

Since 2016, the Real-time Linux project has been a collaborative project under the umbrella of the Linux Foundation. The project’s goal is to make the mainline Linux real-time capable. The project ensures that the Linux kernel developers have the ability to continue development work, long-term support and future research for a real-time-capable Linux.

Rewriting and Refactoring

In the last two years, 2016 and 2017, the Real-time Linux development team rewrote the CPU hotplug infrastructure and refactored the timer wheel and high-resolution timers. This already reduced the out-of-tree PREEMPT_RT patch set significantly.

Due to a funding decrease that became apparent at the beginning of 2018, the development in the Real-time Linux project would have reduced its workforce. Fortunately, Intel and BMW Car IT could close this funding gap. Intel increased their membership from Gold to Platinum and BMW Car IT joined Linux Foundation and the collaborative project as Gold member in the Real-time Linux Project. So now after those project adjustments, the Real-time Linux Project team is back on track and continues to prepare the remaining patches for inclusion into the mainline development with full speed.

In 2018, the Real-time Linux kernel team will be refactoring, rewriting and generally improving the printk and soft interrupt infrastructure and other smaller other parts. This work will prepare the Linux kernel source code so that all further real-time specific changes can smoothly be merged into the mainline kernel.

The real-time functionality touches the core kernel parts (i.e., it requires significant changes in timers, schedulers, locking mechanisms, interrupt handling and more), and it also is a cross-cutting concern for all drivers (i.e., every driver has to follow a certain discipline to make the overall kernel real-time capable). Hence, it is difficult to predict the exact date when the Real-time Linux Project will finally have all its patches merged into the main-line development. However, there is no doubt that the Linux kernel will eventually become real-time capable.

“The Linux kernel is a software development project of huge invest to us. Obviously, BMW Car IT has a high interest of making best possible use of this software asset. The automotive industry has particular requirements, such as higher real-time requirements and the need for longer maintenance periods, than the general IT and consumer electronics industry. With our investments in initiatives addressing these requirements, we can ensure that Linux fits to our needs,” says Kai-Uwe Balszuweit, CEO of BMW Car IT.

Reviewing and Testing

Once the real-time capabilities have been integrated in the main-line development, the project work is of course not just finished and the Real-time Linux project cannot just be abandoned. After the final integration into the main-line development, the development activities will slowly shift its focus:

The core system will not require further changes for the real-time capability, but the Real-Time Linux development team will need to review, test and adjust new incoming features from other kernel development teams to keep the kernel real-time capable when these new features are included.

Furthermore, the already existing real-time stable trees must be further continued to be maintained until the end of life of the corresponding kernel LTS version, so commonly two years for most LTS versions, but possibly even longer. Slowly over the years, the real-time stable trees for older kernel versions will reach their end of life, while for younger LTS kernel versions, which have the real-time capabilities fully included, have no need to maintain a separate real-time stable branch. This will decrease the working effort on the current real-time stable maintainers and they can focus their work to assist in the quality assurance of the continuous main-line development.

Of course, all users and stakeholders of the real-time capability must continue to support all these activities over the next years.

This is well understood at BMW Car IT, and we expect that other companies that require the real-time capability in Linux will also follow and express this general common understanding. Beyond software development until start of production, operations and maintenance is an important software development activity that is not underestimated at BMW Car IT.

Christian Salzmann, the CEO of BMW Car IT, states it clearly: “Providing good software solutions to BMW for many years, BMW Car IT knows that continuous operations and maintenance is one of the major cornerstones for providing a great experience to our customers. The continuous activity of development and operations of software going hand-in-hand, in short DevOps, is part of BMW Car IT’s company mindset. BMW Car IT’s support for further development and operations in the Real-time Linux Project is no exception to this rule.”

Open Source Summit is the place to keep up with the leading edge of Linux, says Linux kernel developer James Bottomley.

It’s no secret that Linux is basically the operating system of containers, and containers are the future of the cloud, says James Bottomley, Distinguished Engineer at IBM Research and Linux kernel developer. Bottomley, who can often be seen at open source events in his signature bow tie, is focused these days on security systems like the Trusted Platform Module and the fundamentals of container technology.

James Bottomley

With Open Source Summit happening this month in conjunction with Linux Security Summit — and Open Source Summit Europe coming up fast — we talked with Bottomley about these and other topics.

The Linux Foundation: How are you involved with Open Source Summit?

James Bottomley: I’m on the program committee, so I’m part of the body responsible for judging the technical content.  Our mission is to try to give a balance to the presentations given at the summit to make sure there’s enough of interest on the technical front to attract the hard core engineering community, while still being a welcoming place for people who have other skills and abilities, thus ensuring a diversity of attendees that encourages interesting conversations and outcomes.

The Linux Foundation: What’s the relevance of Linux in the age of cloud and containers?

Bottomley: The cloud nowadays is moving to be all about containers, and containers absolutely wouldn’t exist without Linux.  If you regard containers as being simply operating system virtualization, then there are many contenders for their place in containers history, like BSD jails and mainframe LPARs.  However, if you view containers through the narrow prism of Docker images, then an absolute requirement is the hardness and backwards compatibility of the Linux Syscall interface: the fact that an Ubuntu Xenial image will still run on top of a RHEL kernel.  This facility is because of Linus’s laser-like focus on maintaining the userspace ABI, which is pretty unique in OS history.

The Linux Foundation: You recently wrote a paper around VMs and container security. Will there by any discussion around that at the event?

Bottomley: Not in the formal presentations, although there probably will be in the hallway.  You have to remember that presentations at the conference are based on proposals that had to be submitted at least six months ago, whereas what I’ve been discussing is based on preliminary research that was only recently completed and published.  This is a general problem for all conferences now that the open source methodology means research goes from ideas to discussions around code in a matter of weeks.

The Linux Foundation: We are living in an age where so much innovation is happening in the tech world, especially in the open source space. What hot technologies are you excited about?

Bottomley: I’m mostly interested in some of the fundamentals of containers and security, including methods for securing the substrate, runtime mechanisms for ensuring immutability, like IMA and also what the next type of container will look like (or more accurately, how do we dump all the unnecessary IaaS components from current container images to realise the true potential of pure application containers).

The Linux Foundation: Who should attend Open Source Summit and why?

Bottomley: I think it’s no secret that Linux is basically the OS of containers and containers are the future of the cloud, so anyone who is interested in keeping up to date with what’s going on in the cloud because this would be the only place they can keep up with the leading edge of Linux.

Bottomley will be speaking at Open Source Summit Europe, as part of the Linux Systems track.  Check out the other scheduled sessions and  sign up to receive updates:

Open Source Summit

Greg Kroah-Hartman talks about the importance of community interaction, and the upcoming Open Source Summit.

People might not think about the Linux kernel all that much when talking about containers, serverless, and other hot technologies, but none of them would be possible without Linux as a solid base to build on, says Greg Kroah-Hartman.  He should know. Kroah-Hartman maintains the stable branch of the Linux kernel along with several subsystems.  He is also co-author of the Linux Kernel Development Report, a Fellow at The Linux Foundation, and he serves on the program committee for Open Source Summit.

Greg Kroah-Hartman (right) talks about the upcoming Open Source Summit. (Image copyright: Swapnil Bhartiya)

In this article, we talk with Kroah-Hartman about his long involvement with Linux, the importance of community interaction, and the upcoming Open Source Summit.

The Linux Foundation: New technologies (cloud, containers, machine learning, serverless) are popping up on weekly basis, what’s the importance of Linux in the changing landscape?

Greg K-H: There’s the old joke, “What’s a cloud made of? Linux servers.” That is truer than most people realize. All of those things you mention rely on Linux as a base technology to build on top of.  So while people might not think about “Linux the kernel” all that much when talking about containers, serverless and the other “buzzwords of the day,” none of them would be possible without Linux being there to ensure that there is a rock-solid base for everyone to build on top of.  

The goal of an operating system is to provide a computing platform to userspace that looks the same no matter what hardware it runs on top of.  Because of this, people can build these other applications and not care if they are running it locally on a Raspberry Pi or in a cloud on a shared giant PowerPC cluster as everywhere the application API is the same.

So, Linux is essential for all of these new technologies to work properly and scale and move to different places as needed.  Without it, getting any of those things working would be a much more difficult task.

LF: You have been involved with Linux for a very long time. Has your role changed within the community? You seem to focus a lot on security these days.

Greg K-H: I originally started out as a driver writer, then helped write the security layer in the kernel many many years ago.  From there I started to maintain the USB subsystem and then co-created the driver model. From there I ended up taking over more driver subsystems and when the idea for the stable kernel releases happened back in 2005, I was one of the developers who volunteered for that.

So for the past 13 years, I’ve been doing pretty much the same thing, not much has changed since then except the increased number of stable trees I maintain at the same time to try to keep devices in the wild more secure.

I’ve been part of the kernel security team I think since it was started back in the early 2000’s but that role is more of a “find who to point the bug at” type of thing.  The kernel security team is there to help take security problem reports and route them to the correct developer who maintains or knows that part of the kernel best.  The team has grown over the years as we have added the people that ended up getting called on the most to reduce the latency between reporting a bug and getting it fixed.

LF: We agree that Linux is being created by people all over the map, but once in a while it’s great to meet people in person. So, what role does Open Source Summit play in bringing these people together?

Greg K-H: Because open source projects are all developed by people who work for different companies and who live in different places, it’s important to get together when ever possible to actually meet the people behind the email if at all possible.  Development is an interaction that depends on trust, if I accept patches from you, then I am now responsible for those changes as well. If you disappear, I am on the hook for them, so either I need to ensure they are correct, or even better, I can know that you will be around to fix the code if there is a problem.  By meeting people directly, you can establish a face behind the email to help smooth over any potential disagreements that can easily happen due to the lack of “tone” in online communication.

It’s also great to meet developers of other projects to hear of ways they are abusing your project to get it to bend to their will, or learn of problems they are having that you did not know about.  Or just learn about new things that are being developed in totally different development groups.  The huge range of talks at a conference like this makes it easy to pick up on what is happening in a huge range of different developer communities easily.

LF: You obviously meet a lot of people during the event. Have you ever come across an incident where someone ended up becoming a contributor or maintainer because of the exposure such an event provided?

Greg K-H: At one of the OSS conferences last year, I met a college student who was attending the conference for the first time.  They mentioned that they were looking for any project ideas that someone with their skill level could help out with. At a talk later that day, a new idea for how to unify a specific subsystem of the kernel came up and how it was going “just take a bunch of grunt work” to accomplish.  Later that night, at the evening event, I saw the student again and mentioned the project to them and pointed them at the developer who asked for the help. They went off to talk in the corner about the specifics that would be needed to be done.

A few weeks later, a lot of patches started coming from the student and after a few rounds of review, were accepted by the maintainer.  More patches followed and eventually the majority of the work was done, which was great to see, the kernel really benefited from their contribution.

This year, I ran into the student again at another OSS conference and asked them what they were doing now.  Turns out they had gotten a job offer and were working for a Linux kernel company doing development on new products during their summer break.  Without that first interaction, meeting the developers directly that worked on the subsystem that needed the help, getting a job like that would have been much more difficult.

So, while I’m not saying that everyone who attends one of these types of conferences will instantly get a job, you will interact with developers who know what needs to be done in different areas of their open source projects.  And from there it is almost an easy jump to getting solid employment with one of the hundreds of companies that rely on these projects for their business.

LF: Are you also giving any talks at Open Source Summit?

Greg K-H:  I’m giving a talk about the Spectre and Meltdown problems that have happened this year.  It is a very high-level overview, going into the basics of what they are, and describing when the many different variants were announced and fixed in Linux.  This is a new security type of problem that is going to be with us for a very long time and I give some good tips on how to stay on top of the problem and ensure that your machines are safe.

Sign up to receive updates on Open Source Summit North America:

Linux kernel

Get insights from Jon Corbet on the state of Linux kernel development.

At the recent Embedded Linux Conference + OpenIoT Summit, I sat down with Jonathan Corbet, the founder and editor-in-chief of LWN to discuss a wide range of topics, including the annual Linux kernel report.

The annual Linux Kernel Development Report, released by The Linux Foundation is the evolution of work Corbet and Greg Kroah-Hartman had been doing independently for years. The goal of the report is to document various facets of kernel development, such as who is doing the work, what is the pace of the work, and which companies are supporting the work.

Linux kernel contributors

To learn more about the companies supporting Linux kernel development in particular, Corbet wrote a set of scripts with the release of kernel 2.6.20, to pull the information out of the kernel repository. That information helped Corbet associate contributions with employers, whenever possible.

When Corbet published a report based on these findings in LWN, it created a bit of a stir. “It was a surprise to everyone, including me, because there was still this image of free software in general and Linux in particular as being something produced by kids who haven’t moved out of their parents basements,” said Corbet.

He found that more than 70 percent of the code going into the kernel was coming from professional developers who were getting paid to do that work. “Since then things have changed and our numbers have gotten better. Today, over 90 percent of the code is coming from professional developers who are employed by some company to work on the kernel,” he said.

Corbet has been involved with the Linux kernel from a very early stage, so connecting the dots was not too difficult, even though not all developers use official company email accounts,

“In most cases, we know who is working for which company. Sometimes people contact us and say that their employer wants to ensure that they do get credit for the work they are doing in the kernel. Sometimes we just ask who they are working for,” said Corbet.

Corbet not only gathers valuable data about the Linux kernel, he also analyzes the data to see some patterns and trends. The biggest trend, over the years, has been a decline in the number of contributions coming from volunteers, which has decreased from 15 percent to 6 percent since the 2.6.20 release.

“There are times when we have worried about it because volunteers are often the people who are in the next round of paid developers. That’s often how you get into the community — by doing a little bit of stuff on your own time,” he said. Corbet did a bit of digging to see the employment status of people when their very first patch merged and their latest status. He found that at this point most of those people were already working for some company.

While it’s true there are fewer volunteer developers now, it could also be said that people don’t remain volunteers for very long because when their code gets merged into the kernel, companies tend to approach these developers and offer jobs. So, if your code shows up in the kernel, that’s a good resume to have.

What keeps Corbet awake at night

There has been a growing concern of late that the Linux kernel community is getting older. Looking at the top maintainers, for example, you can see a lot of people who have been involved since the 1990s.

“The upper cadre is definitely getting a little bit older, a little bit grayer. There is some truth to that and I think the concerns of that are not entirely overblown,” said Corbet. “A whole bunch of us managed to stumble into something good back in the ’90s, and we have stuck with it ever since because it’s been a great ride.”

That doesn’t mean new people are not coming in. A new kernel is released every 9 to 10 weeks. And, every new release sees contributions from more than 200 developers submitting their very first patch.

“We are bringing a lot of new people into the community,” Corbet said. “Maybe half of those 200 contributors will never contribute anything again. They had one thing they wanted to fix and then they moved on. But there are a lot many others who stick around and become long-term members of the community. Some of these worked their way into the subsystem maintainer positions. They will be replacing the older members as they retire.”

Corbet is not at all worried about the aging community as it has evolved into an “organic” body with continuous flow of fresh blood. It’s true that becoming a kernel developer is more demanding; you do have to work your way into it a little bit, but plenty of people are doing it.

“I’m not really worried about the future of our community because we are doing so well at attracting bright new developers,” said Corbet, “We have an influx rate that any other project would just love to have.”

However, he did admit that the community is showing increasing signs of stress at the maintainer level. “The number of maintainers is not scaling with a number of developers,” he said. However, he said, this problem is not unique to the kernel community; the whole free software community is facing this challenge.

Another concern for Corbet is the emergence of other kernels, such as Google’s Fuchsia. These kernels are being developed specifically to be permissively licensed, which allows them to  be controlled by one or a very small number of companies. “Some of those kernels could push Linux aside in various subfields,” said Corbet. “I think some of the corporate community members have lost sight of what made Linux great and so successful. It could be useful for some companies in the short term, but I don’t think it’s going to be a good thing for anyone in the long term.”

Core needs

Corbet also noted another worrisome trend. Although many companies contribute to every kernel release, if you look closely you will see that a lot of these contributions are toward making their own hardware work great with Linux.

“It’s a great thing. We have been asking them to do it for years, but there is a whole lot of the kernel that everyone needs,” he said. There is the memory management subsystem. There’s the virtual filesystem layer. There are components of the kernel that are not tied to any single company’s hardware, and it’s harder to find companies willing to support them.

“Some of the companies that contribute to the most code to the kernel do not contribute to the core kernel at all,” said Corbet.

Corbet also worries about the lack of quality documentation and has himself initiated some efforts to improve the situation. “Nobody wants to pay for documentation,” he said. “There is nobody whose job it is to write documentation for the kernel, and it really shows in the quality. So, some of those areas I think are really going to hurt us going forward. We need to get better investment there.”

You can hear more from Jon Corbet, including insights on the recent Spectre and Meltdown issues, in his presentation from Embedded Linux Conference:

You can learn more about the Linux kernel development process in the complete annual report. Download the 2017 Linux Kernel Development Report now.

linux kernel developer

Linux kernel developer Steven Rostedt maintains the Real Time Stable releases of the Linux kernel.

Linus Torvalds recently released version 4.16 of the Linux kernel. These releases typically occur every nine to ten weeks, and each one contains the work of more than 1,600 developers representing over 200 corporations, according to the 2017 Linux Kernel Development Report, written by Jonathan Corbet and Greg Kroah-Hartman. In this series, we’re highlighting some of the developers who contribute to the kernel.

Steven Rostedt, Open Source Programmer at VMware, maintains the Real Time Stable releases of the Linux kernel, among other things. Rostedt is one of the original developers of the PREEMPT_RT patch and began working on it in 2004 with the goal of turning Linux into a real-time designed operating system. He is also the main author, developer, and maintainer of Ftrace, a tool designed to help developers find what is going on inside the kernel. According to the Ftrace wiki, the tool can be used for debugging or analyzing latencies and performance issues that take place outside of user-space.

Linux kernel dev

Steven Rostedt

Additionally, this past year, Rostedt found time to speak at various events and serve on The Linux Foundation’s technical advisory board. Here are Rostedt’s responses to our questions.

Linux Foundation: What role do you play in the community and what subsystem(s) do you work on?

Steven Rostedt: I partake in a lot of the Linux Foundation events as well as Kernel Recipes, Linux Plumbers, sometimes Linux Tag and other events. I’m on The Linux Foundation’s Technical Advisory Board (TAB) and was on the Linux Plumbers programming committee. I’m an Open Source advocate and try to communicate to people what that means. I maintain the Real Time Stable releases, and the Ftrace (Linux kernel tracer) subsystem, as well as ktest, localmodconfig, and Ftrace tools like trace-cmd and KernelShark.

Linux Foundation: What have you been working on this year? / What’s one way you have contributed to the 4.8 to 4.13 releases?

Rostedt: I’ve been working on having ftrace trace init functions in both the main kernel core as well as in modules. Between 4.8 and 4.13, I rewrote the function tracing trigger code to be able to be expanded and used to enable function filtering for tracing on modules before they are loaded.

Linux Foundation:  What do you think the kernel community needs to work on in the upcoming year?

Rostedt: I think more focus should be on eBPF and helping it be easier to use as well as having an eye on security. Running a VM within the kernel can be very dangerous, and people need to use caution and be extra careful during development.

Linux Foundation: Why do you contribute to the Linux kernel?

Rostedt: Because it is the one place that you have total control over your computer.

At the recent Embedded Linux Conference, Rostedt presented a session on “Maintaining a Real Time Stable Kernel,” in which he explained what’s required to maintain a stable RT tree, which is a bit different from maintaining a normal stable tree. In this talk, he covered various tools that can be used and described the current tests performed to ensure that the RT stable kernel is fully functional.

You can learn more about the Linux kernel development process and read more developer profiles in the full report. Download the 2017 Linux Kernel Development Report now.

To find and report bugs, Linux kernel developers depend on a wide community of testers.

A kernel that has had nearly 83,000 patches applied will certainly have a few bugs introduced along with the new features, states the 2017 Linux Kernel Development Report, written by Jonathan Corbet and Greg Kroah-Hartman.Linux kernel

To find and report those bugs, Linux kernel developers depend on a wide community of testers. And, according to convention, when a bug-fixing patch is applied to the kernel, it should contain a “Reported-by” tag to credit the tester who found the problem. During the period covered by the most recent report, more than 4,100 patches carried such tags, and the top 21 bug reporters are shown in the table at right.

Julia Lawall, Senior Researcher at Inria, is one of the developers involved in the bug reporting process, as she works on the Coccinelle tool that is used to find bugs in the kernel. Here, Lawall answers a few questions about her contributions to the development process.

Linux kernel

Julia Lawall

The Linux Foundation: What role do you play in the community and what subsystem(s) do you work on?

Julia Lawall: I work on the tool Coccinelle that is used to find bugs in the Linux kernel and perform large-scale evolutions.

The Linux Foundation: What have you been working on this year?

Lawall: This year I have been working with Bhumika Goyal on making various kernel structures read-only. We have constified over 1500 structures this year. This work has also motivated various bug fixes and performance improvements in Coccinelle.

I have also been working on automatically identifying patches that should be considered for backporting to stable kernels, in collaboration with Greg K-H, Sasha Levin, and colleagues at Singapore Management University. Our approach is still work in progress, but several hundred commits that were not originally tagged for stable have been identified and applied to stable versions.

The Linux Foundation: What do you think the kernel community needs to work on in the upcoming year?

Lawall: Initial experiments suggest that the rate of propagation of commits to stable is rather uneven across the kernel. This can be due to the different properties of different subsystems, but there can also be room for maintainers to annotate commits for stable kernels more frequently and consistently.

The Linux Foundation: Why do you contribute to the Linux kernel?

Lawall: Many reasons: the potential impact, the challenge of understanding a huge code base of low-level code, the chance to interact with a community with a very high level of technical skill.

You can learn more about the Linux kernel development process and read more developer profiles in the full report. Download the 2017 Linux Kernel Development Report now.

Shuah Khan

Shuah Khan, of Samsung Research America, is a Linux kernel contributor and maintainer.

The Linux kernel development community remains extremely busy, as shown in the recent Linux Kernel Development Report, written by Jonathan Corbet and Greg Kroah-Hartman. Since the 4.7 release, just under 83,000 changesets have been merged from 4,319 individual developers representing 519 known corporations. Part of this busy development process involves the kernel testing infrastructure. According to the report, the “zero-day build and boot robot” system alone found 223 bugs (all of which were fixed) during the most recent reporting period. The in-kernel self-test framework continues to improve and will someday be a comprehensive test suite for the kernel.

Shuah Khan

Shuah Khan

Shuah Khan, Senior Linux Kernel Developer at Samsung Research America, is the maintainer of the kernel self-test framework. In this article, Khan answers a few questions about her work on the Linux kernel.

The Linux Foundation: What role do you play in the community and what subsystem(s) do you work on?

Shuah Khan: I maintain the Linux kernel self-test framework and USB-over-IP driver. I also contribute to the Linux Media, Power Management, IOMMU, and DMA areas. I publish articles related to the Linux kernel on the Samsung Open Source Group (OSG) blog and have previously written for the Linux Journal, where I authored a paper on Linux Kernel Testing and Debugging.

The Linux Foundation: What have you been working on this year? 

Khan: My main focus this year has been Exynos platform upstream stability, Kselftest framework and individual tests. I contributed to improving the quality of media subsystem core, and media and drm drivers on Exynos platform. I enhanced and improved the Kselftest framework by adding support for the Test Anything Protocol and object relocation. In addition, I boot tested stable kernel release candidates and maintained the Kselftest and USB-over-IP drivers.

The Linux Foundation: What do you think the kernel community needs to work on in the upcoming year?

Khan: The Linux Kernel community should continue its focus on adding support for new hardware, harden the security, and improve quality. Focusing on effective ways to proactively detect security vulnerabilities, race conditions, and hard-to-find problems will help towards achieving the above goals. As a process issue, community would have to take a close look at the maintainer to developer ratio to avoid maintainer fatigue and bottlenecks.

The Linux Foundation: Why do you contribute to the Linux kernel?

Khan: Contributing to the Linux kernel requires a unique set of skills in addition to the technical know-how. Contributors should be open to their ideas and work challenged and questioned, be ready to accept criticism, be open and flexible to evolve their ideas and work based on feedback from other contributors. It is an iterative process of review and refinement to evolve a fix or a feature that adds value to the kernel. I enjoy the technical challenges and being part of the community that works towards a common goal of making the Linux kernel better in each release.

You can learn more about the Linux kernel development process and read more developer profiles in the full report. Download the 2017 Linux Kernel Development Report now.

linux kernel

The top 30 Linux kernel developers have contributed about 16 percent of the total changes since the start of the Git era.

Since the beginning of the Git era (that is, the 2.6.11 release in 2005), a total of 15,637 developers have contributed to the Linux kernel, according to the recent Linux Kernel Development Report, written by Jonathan Corbet and Greg Kroah-Hartman.

Thomas Gleixner

Thomas Gleixner

The report states that, since the 2.6.11 release, the top 10 developers together have contributed 45,338 changes — almost 7.1 percent of the total. The top 30 developers contributed just under 16 percent of the total, as seen in the table below.

One of these top 30 developers is Thomas Gleixner, CTO at Linutronix GmbH, who serves in various kernel maintainer roles. In this article, Gleixner answers a few questions about his contributions to the Linux kernel.Linux kernel devs

Linux Foundation: What role do you play in the community and what subsystem(s) do you work on?

Thomas Gleixner: I serve various maintainer roles. The x86 architecture, the generic interrupt subsystem and the time(r) subsystem. Aside of that I’m leading the realtime preeemption project and overseeing the mainlining of it.

Linux Foundation: What’s one way you have contributed to the 4.8 to 4.13 releases?

Gleixner: Reviews and other maintainer duties, reworking CPU hotplug and the timer wheel, implementing the managed interrupt facility, helping the resource director technology support along and consolidation/cleanups all over the place.

Linux Foundation: What do you think the kernel community needs to work on in the upcoming year?

Gleixner: Aside of the technical challenges, which are hard to predict, we need more effort on code cleanup and consolidation along with more capacity for reviews.

Linux Foundation: Why do you contribute to the Linux kernel?

Gleixner: First of all, it’s fun, and I strongly believe that FOSS is the right way to go, but I freely admit that I also do it to earn my living.

You can learn more about the Linux kernel development process and read more developer profiles in the full report. Download the 2017 Linux Kernel Development Report now.

This free guide can help you increase your development team’s efficacy through and with open source contributions.

Open source programs are sparking innovation at organizations of all types, and if your program is up and running, you may have arrived at the point where maximizing the impact of your development is essential to continued success. Many open source program managers are now required to demonstrate the ROI of their technology development, and example open source report cards from Facebook and Google track development milestones.

This is where the new, free Improving Your Open Source Development Impact guide can help. The aim of the guide is to help you increase your development team’s efficacy through and with open source contributions. By implementing some of the best practices laid out in the guide, you can:

  • Reduce the amount of work needed from product teams
  • Minimize the cost to maintain source code and internal software branches
  • Improve code quality
  • Produce faster development cycles
  • Produce more stable code to serve as the base for products
  • Improve company reputation in key open source communities.

Open source development requires a different approach than many organizations are accustomed to. But the work becomes easier if you have a clear plan to follow. Fortunately, a whole lot of companies and individuals have already forged a path to success in contributing to significant open source projects. They have tried and true methods for establishing a leadership role in open source communities.

This open source guide offers lessons for increasing open source development impact through specific examples. Contributing to the Linux kernel is one of the hardest challenges for open source developers. With that in mind, the guide uses this case as an example, but the lessons learned will apply to nearly any open source project you’ll work with.

“It took us years of constant discussion and negotiation to break from the traditional IT setup into a more flexible environment that supports our open source development,” said Ibrahim Haddad, Vice President of R&D and Head of the Open Source Group at Samsung Research. “We made it work for us and with enough persistence you also can make it work for your open source team.”

Common Challenges

Notably, organizations run into common problems as they try to improve the impact of their open source inventions. The figure below shows some of the challenges that dedicated open source teams face in an enterprise setting.open source guidesThe Improving Your Open Source Development Impact guide can help you navigate these and other common open source-related challenges. It covers everything from evaluating ROI to optimizing practices, and it explores how to seamlessly and safely leverage existing tools to complement your open source creations.

It is one of a new collection of free guides from The Linux Foundation and The TODO Group providing valuable insight and expertise for any organization running an open source program. The guides are available now to help you run an open source program office where open source is supported, shared, and leveraged.

Check out the all the guides, and don’t miss the previous articles in the series:

How to Create an Open Source Program

Tools for Managing Open Source Programs

Measuring Your Open Source Program’s Success

Effective Strategies for Recruiting Open Source Developers

Participating in Open Source Communities

Using Open Source Code

Launching an Open Source Project: A Free Guide

linux kernel development

Part of the ongoing Linux development work involves hardening the kernel against attack.

Security is paramount these days for any computer system, including those running on Linux. Thus, part of the ongoing Linux development work involves hardening the kernel against attack, according to the recent Linux Kernel Development Report.

This work, according to report authors Jonathan Corbet and Greg Kroah-Hartman, involves the addition of several new technologies, many of which have their origin in the grsecurity and PaX patch sets. “New hardening features include virtually mapped kernel stacks, the use of the GCC plugin mechanism for structure-layout randomization, the hardened usercopy mechanism, and a new reference-count mechanism that detects and defuses reference-count overflows. Each of these features makes the kernel more resistant to attack,” the report states.

Linux kernel

Kees Cook

In this series, we are highlighting some of the hard-working developers who contribute to the Linux kernel. Here, Kees Cook, Software Engineer at Google, answers a few questions about his work.

Linux Foundation: What role do you play in the community and what subsystem(s) do you work on?

Kees Cook: Recently, I organized the Kernel Self-Protection Project (KSPP), which has helped focus lots of other developers to work together to harden the kernel against attack. I’m also the maintainer of seccomp, pstore, LKDTM, and gcc-plugin subsystems, and a co-maintainer of sysctl.

Linux Foundation: What have you been working on this year?

Cook: I’ve been focused on KSPP work. I’ve assisted many other developers by helping port, develop, test, and shepherd things like hardened usercopy, gcc plugins, KASLR improvements, PAN emulation, refcount_t conversion, and stack protector improvements.

Linux Foundation: What do you think the kernel community needs to work on in the upcoming year?

Cook: I think we’ve got a lot of work ahead in standardizing the definitions of syscalls (to help run-time checkers), and continuing to identify and eliminate error-prone code patterns (to avoid common flaws). Doing these kinds of tree-wide changes continues to be quite a challenge for contributors because the kernel development model tends to focus on per-subsystem development.

Linux Foundation: Why do you contribute to the Linux kernel?

Cook: I’ve always loved working with low-level software, close to the hardware boundary. I love the challenges it presents. Additionally, since Linux is used in all corners of the world, it’s hard to find a better project to contribute to that has such an impact on so many people’s lives.

You can learn more about the Linux kernel development process and read more developer profiles in the full report. Download the 2017 Linux Kernel Development Report now.