Linux's first-ever official “embedded maintainers” have invited device developers to get involved in the kernel development process. Doing so will pay dividends when it comes time to spin a product variant or firmware update, say Paul Gortmaker and David Woodhouse, in a stereo interview with Linux Weekly News.

Andrew Morton called for greater embedded representation in kernel development (Click for more on the history of Linux's embedded maintainer role)

The “embedded maintainer” role shared by Gortmaker and Woodhouse was created last month, largely at the behest of 2.6-series kernel maintainer Andrew Morton (pictured at right). A former embedded engineer who helped build set-top boxes for Digeo, Morton suggested the idea last fall in a keynote at MontaVista's VisionSummit (now an annual event). Morton reiterated the wish more strongly at the Embedded Linux Conference held by CELF in mid-April, and then privately sent out an RFC (request for comment) on the idea, after which Gortmaker and Woodhouse stepped up to volunteer.

The biggest problem — not enough embedded developer involvement

In their LWN interview, Gortmaker and Woodhouse both observe that embedded Linux developers are typically focused on getting products out the door, and may feel they lack the time to interface with the Linux kernel developer community, or follow kernel developer best practices. Yet, doing so will ultimately save time, the two contend.

Gortmaker reportedly explained, “A lot of times, a group who is developing for an embedded platform is focused 100 percent on getting their product up, running, and deployed. The developers involved aren't necessarily hard core Linux folks, and it usually plays out by them picking a kernel version, getting their stuff in their local tree, and that is it. They may not know git, they probably don't have insight into who the respective subsystem maintainers are, they may perceive LKML as too hostile, or they may not have management buy-in on trying to push stuff upstream. But inevitably, some time passes, and then they have a carry forward task where they try and do a big jump uprev of all their changes, and this repeats forever.

“Most people who have had to endure the jump uprev vs. a continual tracking and carrying of changes will tell you the jump is not the way to go for a multitude of reasons,” Gortmaker reportedly continued, “But it seems a lesson that everybody ends up having to learn on their own. So, I'm hoping we can get some of these people more aligned with the typical Linux developer workflow — i.e., work from the latest codebase, create logical changesets that can be submission candidates, etc.”

In the same LWN interview, Woodhouse echoes, “People are too focused on getting their stuff out the door as quickly as possible without much thought to working with upstream. Managers aren't budgeting the time to get things merged, and engineers aren't talking about their design early enough that it can be improved before it's a fait accompli. That extra time isn't just about being a good citizen — failing to do it almost always comes back to bite you personally, when you come to do a new product, a product update, or even need to merge in changes from upstream to fix bugs. But everybody seems to need to learn that the hard way.”

Said David Woodhouse, as reported by LWN.net, “People seem to have forgotten how long it took us to educate the enterprise vendors and get them to work nicely with us; we're a bit behind the curve on the embedded side but we're getting there. And organizations like CELF are doing good work on that front, too.”

Other goals

Additional goals mentioned by the two in their LWN interview include:

• Providing a forum (the new [email protected] list) for embedded developers to learn about the kernel development process
• More testing of non-x86 architectures, for example testing drivers with the PREEMPT_RT patch, so it can someday be merged
• Adding features motivated by embedded requirements
• Watching out for kernel changes likely to affect embedded users negatively
• Cultivating a “big-picture” awareness of embedded requirements
• Merging a more modern flash filesystem than JFFS2, such as LogFS or UBIFS
• Revamping the MTD (memory technology devices) API

Additionally, Woodhouse has for the time being established an embedded git tree, here, in response to a patch sent to the linux-embedded list by Tim Bird. CELF moved away from maintaining separate patchsets some years ago, instead adopting a policy of mainline participation.

The complete interview with Gortmaker and Woodhouse can be found in the “Kernel” section of the Linux Weekly News, here. An archive of the linux-embedded mailing list can be found here, here, or here. To subscribe, send a message with “subscribe linux-embedded” in the message body to [email protected]

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.