Some views from Vision

Your editor had the honor of speaking at MontaVista's Vision 2008 conference recently. This conference - a gathering of MontaVista's customers - provided an opportunity to observe how (part of) the embedded industry sees itself and its role in the larger Linux community. Relations between embedded systems and Linux as a whole have often been a little uneasy; a situation which probably will not change in the near future. That said, there are signs that embedded developers are starting to think about the value of engaging more directly with the development community that they depend on.

William Mills is the Chief Technologist for Open Linux Solutions at Texas Instruments; his brief presentation at Vision was an interesting demonstration of how attitudes in the industry are changing. According to Mr. Mills, TI's method for developing Linux drivers for its products involved doing the work behind closed doors, then distributing the result through MontaVista. That approach has changed, though. TI now does its driver work in a public git tree, with a focus on merging the code upstream as a first priority. Customers who want to work directly with upstream kernels can get the code directly.

In a sense, it would appear that TI has removed MontaVista as the intermediary which distributes drivers for TI hardware. But TI still distributes code through MontaVista, so customers looking for a supported, integrated offering can still get a distribution which suits their needs. There's no shortage of embedded systems vendors who lack the skills and the desire to support a Linux distribution themselves; for those vendors, buying a supported system makes a lot of sense. For everybody else, the software is free and part of the mainline kernel, as it should be.

MontaVista founder Jim Ready discussed "the state of embedded Linux," focusing on areas where there is a bit of a mismatch between what the Linux community is providing and what the embedded industry needs. Certain kinds of functionality are missing; the ability to do user-space interrupt synchronization was one example. The rate of change in the kernel is very high, presenting embedded vendors with the difficult choice of backporting fixes or upgrading to a more recent kernel. Tracing and profiling tools are not up to the level needed by the industry.

Jim also talked some about realtime functionality, which currently must be patched into the kernel separately. He complained that changes made to the mainline kernel often break the realtime patch sets, leaving developers scrambling to make things work again. Keeping these patches in a working state requires constant effort; it is a significant cost.

All of this may sound like whining from an industry which has earned a reputation for taking more from Linux than it is willing to put back in. But Jim put the blame directly on the embedded industry itself; embedded vendors, he says, still haven't quite gotten it. While taking some pride in MontaVista's position in the list of top contributors to the kernel, he suggested that MontaVista should be enjoying the company of more embedded systems firms. The embedded industry should be contributing more to the kernel than it is.

What it comes down to, says Jim, is that the center of gravity in the Linux development world can be found in enterprise computing. Vendors in that industry are contributing heavily to the kernel and, as a result, the kernel tends to fit their needs better. The embedded community needs to get together and figure out how it, too, can become a more prominent contributor and work to drive the kernel in directions which suit its needs.

Judging from the response in the room, many of those in the audience seem to agree with this point of view. Some see it differently, though. During your editor's talk, a member of the audience asked whether the embedded community should stop using a kernel developed by enterprise system vendors and, instead, make its own version of the kernel suited to its needs. Needless to say, your editor discouraged this approach; the cost of forking the kernel and fragmenting the development community would vastly exceed the value of any benefits gained. But the questioner seemed unconvinced.

The clear conclusion to be made from that exchange is that there are still people in the embedded industry who do not see the value of working with the larger Linux development community. It is easy to fault the embedded community for its failure to contribute back, but it also makes sense to look in the mirror and ask if we couldn't make a more persuasive case for joining in. There has been a sustained effort to encourage the embedded systems industry to become a full participant in our community; over the years, that work has yielded a steady stream of successes. By continuing and improving this work, we'll continue the process of bringing our community together. Then we'll truly have a single system that runs on everything from wrist watches to supercomputers.

---

(Log in to post comments)