feature article
Subscribe Now

Making More of a Contribution

Increasing Embedded’s Influence on Linux

Peer review is a well-established essential component of the scientific process. For good science, anyway. The system provides a way for new ideas to be vetted and tested rather than being foisted immediately on a public that is all too willing to accept at face value the pronouncements of anyone calling him- or herself a scientist.

The same idea, albeit with somewhat different aims, plays a part in the open source world, where code gets posted and reviewed by peers in order to ensure that the code actually does what is claimed, has no bugs, is well structured, meets the needs of a variety of environments, and is robust and maintainable. Any such process is going to have an aspect of back-and-forth in it, where peers raise issues or questions and the authors respond either with changes, explanations, or defense of choices made. Hopefully with a minimum of snarkage and collateral personal destruction.

The Linux world provides formalized ways of doing this, with repositories for posting code until clean, at which point it becomes a candidate for inclusion in a future version of Linux on kernel.org, the “official” Linux distribution vehicle. Anyone can contribute code, but not everyone does. In fact, at MontaVista’s recent VISION conference, CTO Jim Ready pointed out that of the top contributing companies to Linux, only one from the embedded world (surprise – MontaVista) was in the top 30, at number 9, with 1.2% of the contributions. Everyone else was enterprise- or PC-oriented. It didn’t seem like Jim was using this fact to pat MontaVista’s back, but rather to suggest that the embedded community isn’t doing its part in improving Linux. And this can come at a real cost, since embedded systems have significant requirements that won’t necessarily be considered without staunch embedded advocates.

Because versions of Linux are available both from kernel.org and commercially, a key early project decision for embedded developers is which version of Linux to use and from which source. Kernel.org doesn’t claim to provide a commercial product, but rather the leading edge in features. They leave the tidying up to the commercial providers, who package it up into neat bundles, perform the usual product QA, and, not least, support the code. The question is, which software gets commercialized? Stuff that’s already been vetted thoroughly or the newest stuff?

This may sound like a dumb question, since clearly some designers are going to want access to the newest stuff as soon as possible. To this end, TI’s William Mills proposed a new model for getting new versions into the community more quickly. Historically, they’ve taken their DSP drivers and such and have worked with the commercial providers early, getting through the commercialization process, after which the software goes out to the community via their “davinci tree.” At this point it becomes visible for other engineers to play with and check out; once solid, it can proceed to kernel.org. The problem with this is that the public doesn’t see the code until after productization is complete: by the time Joe Engineer starts asking questions about the code, the poor dude that wrote the code has been working on a new project, having put a satisfying check mark by the old project. Now some self-important poser is asking questions about code that’s been duly repressed in memory, for release only in the comfort of the therapist’s couch. Dredging that up in any other environment is distracting at the very least, and it certainly makes for less speedy (and perhaps less cheerful) resolution of any issues raised.

The alterative proposed by TI, and endorsed by MontaVista, is getting the code out to the community as early as possible so that it can be reviewed more quickly while still near top-of-mind for the developers. This can provide speedier closure for those involved in the project. Meanwhile, the commercial entities can also pull from the community chest to start productizing the software. Hence their mantra: “community first, commercial complement.”

There are a couple practical challenges here. First, once the software goes out to the community, it starts changing as fixes and clean-up proceed. Presumably the commercial companies will pull at some point to start building the product, and they’ll be pulling from a moving target. Commercial availability could be delayed by a decision to hold off until the rate of change slows. While that could push things out a bit, it certainly would result in a more stable first release as compared with the current way of doing things, where the code doesn’t go to the public until the commercial company is done with it. So not really that much of a killer.

The second, tougher acknowledged challenge is one faced by designers as they decide which version to use for a project. Once you’ve locked onto a version, you really don’t want to change that midstream.  So if you pick a nice stable commercial offering, it will lag the latest features since, by design, work can’t start on packaging those features until they’re public. If you want the latest features, you have to pull from the public tree; now you’re working a bit more blind, without the benefit of the commercial infrastructure. A higher skill level is required, and there’s really no support.

What you’d like to be able to do is start, if necessary, with the public version to enable needed new features, and then transition over the commercialized embodiment of that version once it’s available. Doing that smoothly without running undue risk of injecting new bugs or suffering the delay of a new verification step is a problem that remains to be solved.

While this might at first seem to be something that would put a company like MontaVista at a disadvantage, since they can’t offer new features as quickly, they are in fact supportive because it has the potential to put embedded developers back into the process of contributing to Linux. Right now it’s all on the commercial guys because ultimately what ends up public is the commercialized version. By making the new stuff available to the world directly and earlier, the creators of that software – and the early-adopting developers that choose to work with and modify the pre-commercial version – will be able to contribute directly, without the MontaVistas of the world being intermediaries. Giving embedded developers more immediacy with respect to Linux can hopefully increase the amount of embedded contribution, adding some balance to what is now a pretty lopsided picture.

Leave a Reply

featured blogs
Dec 1, 2023
Why is Design for Testability (DFT) crucial for VLSI (Very Large Scale Integration) design? Keeping testability in mind when developing a chip makes it simpler to find structural flaws in the chip and make necessary design corrections before the product is shipped to users. T...
Nov 27, 2023
See how we're harnessing generative AI throughout our suite of EDA tools with Synopsys.AI Copilot, the world's first GenAI capability for chip design.The post Meet Synopsys.ai Copilot, Industry's First GenAI Capability for Chip Design appeared first on Chip Design....
Nov 6, 2023
Suffice it to say that everyone and everything in these images was shot in-camera underwater, and that the results truly are haunting....

featured video

TDK CLT32 power inductors for ADAS and AD power management

Sponsored by TDK

Review the top 3 FAQs (Frequently Asked Questions) regarding TDK’s CLT32 power inductors. Learn why these tiny power inductors address the most demanding reliability challenges of ADAS and AD power management.

Click here for more information

featured paper

3D-IC Design Challenges and Requirements

Sponsored by Cadence Design Systems

While there is great interest in 3D-IC technology, it is still in its early phases. Standard definitions are lacking, the supply chain ecosystem is in flux, and design, analysis, verification, and test challenges need to be resolved. Read this paper to learn about design challenges, ecosystem requirements, and needed solutions. While various types of multi-die packages have been available for many years, this paper focuses on 3D integration and packaging of multiple stacked dies.

Click to read more

featured chalk talk

Introduction to the i.MX 93 Applications Processor Family
Robust security, insured product longevity, and low power consumption are critical design considerations of edge computing applications. In this episode of Chalk Talk, Amelia Dalton chats with Srikanth Jagannathan from NXP about the benefits of the i.MX 93 application processor family from NXP can bring to your next edge computing application. They investigate the details of the edgelock secure enclave, the energy flex architecture and arm Cortex-A55 core of this solution, and how they can help you launch your next edge computing design.
Oct 23, 2023
4,785 views