The Linux kernel develops at a truly astonishing pace, with a new major version emerging every two to three months. For both new and already active kernel developers, keeping up with changes and new features is both challenging and worthwhile. With the recent release of kernel 3.5, we wanted to share our philosophy for having the most up-to-date materials in our courses.
At the Linux Foundation, we have a number of Linux training course offerings that focus on kernel development (particularly LF320 Linux Kernel Internals and Debugging and LF331 Developing Linux Device Drivers). Because the Linux Foundation is very closely tied to the kernel development community, we are in a unique position to quickly take advantage of the latest and greatest features and offer them in our courses.
It is very important to us at the Linux Foundation to ensure our training attendees receive only the most up-to-date and relevant information and to encourage the use of new and improved methods, with an eye on future trends in development.
While our attendees can range from experienced programmers with little Linux and/or kernel experience up to veterans, the bulk tend to be experienced and competent, but relatively new to kernel development. Our goals for our Linux courses are to focus on getting attendees comfortable in the Linux ecosystem and bringing them up to speed quickly.
We take very seriously the task of having them adopt the newest methods and avoiding using relatively antiquated ones that, while still supported, are effectively deprecated and may vanish in the future.
How Training Materials Stay Updated
Keeping our Linux training materials and instructors in synchronization with the moving target of new kernel releases is almost an obsession of ours. To give an example, we began offering Linux Kernel Internals and Debugging [LF320] in November 2009, when the kernel was at version 2.6.31; with the current release being 3.5, there have been 14 major releases since them. LF320 has had eight major revisions in that period.
Depending on various factors, we put out a new version of our training materials at least at every other kernel release. Revise and release often has always been our operating method.
Methods we use to ensure currency of our Linux training include:
1) Our courseware developers take the time to monitor (and sometimes contribute to) the Linux Kernel Mailing List to watch developments in real time. We also closely monitor the Linux Weekly News, which consistently provides the most informed and competent coverage of Linux kernel development and trends.
2) Almost all printed references to kernel code in our Linux course materials contain both version and line numbers. This forces our courseware developers to check them every time a new kernel appears to see exactly what changes (if any) will affect the course materials and revise accompanying course text as appropriate.
It is not at all unusual to find significant differences this way that have not been noticed by simply following mailing lists and websites. Fields appear and disappear in data structures and even very old device drivers are rewritten to use newer methods and styles. We force ourselves to catch these modifications.
3) Our Linux courses are hands-on and exercise-based with most of the laboratories involving writing C code. All the example solutions code is verified to work with the newest kernel version and any adjustments and version dependence is coded in. We generally start this process well before the final release of the kernel by testing against release candidates.
All solutions are tested against both 32- and 64-bit Linux distributions from all major vendors. We make sure the solutions work both with the latest vanilla releases from kernel.org as well as distributor kernels; at this point we have full compatibility without modification going back at least as far as 2.6.32 and easy adaptation to earlier kernels.
4) Our instructors are made aware of pending changes and are asked for input before things are finalized; the instructors are the key link to the needs and demands of attendees and they play an active role in shaping content. They receive the new material immediately as it becomes available and we instantly swap it in for both the printed manuals and the instructor’s teaching materials.
While we want to promote new methods as good practice we also try to avoid premature promotion of new features (at least in detail), since it often takes a couple of kernel releases for new features to stabilize. So at first, we’ll add short descriptions in highlighted boxes and then later, develop new sections and sub-sections with detailed explanations of how to use them.
For example, we have introduced and then fully developed topics such as threaded interrupt handlers and high precision kernel timers (both of which arose from the real time preemption patch series) and tracing and debugging tools such as ftrace, perf and powertop. As new features get added we constantly rewrite.
Best Practices Help Everyone
When one looks at Linux training materials offered by other providers, one often sees features that are completely obsolete or deprecated appearing in the outlines. This is a red flag that either that the Linux training material hasn’t been updated significantly for years or doesn’t really exist.
We have other Linux courses that are more oriented to the user side and thus, are less dependent on exact kernel versions, such as LF312 Developing Applications for Linux, LF211 Introduction to Linux for Developers, and LF262 Developing with Git. While we don’t update them quite as often as the kernel-based classes, we still update them frequently to incorporate new material, improve the exposition, fix any errors, etc.
We believe we are helping our training attendees work efficiently (and enjoyably) as members of the open source community. Getting them to adopt best practices (often at the early stages of their journey) is of benefit to the entire community and expands it ranks.
============================================================
Jerry Cooperstein, PhD
Training Program Director
The Linux Foundation
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
============================================================
