I just attended the Global Signal Processing Expo (GSPx) held at the Santa Clara Convention Center from Sep 27-30. This conference targets a broad range of signal processing applications including automotive, consumer electronics, defense/aerospace, telecommunications, and wireless. The conference places a special emphasis on Software Defined Radio, Wi-Fi, and multi-media. Clearly, GSPx goes well beyond the embedded use of off-the-shelf DSP hardware. The conference is not entirely new - founder Amnon Aliphas has successfully presented signal-processing-focused events and other embedded systems conferences for the past decade.
GSPx featured over 500 papers, 4 keynote addresses, 10 half-day technical workshops, 10 panels, and numerous presentations and exhibits from dozens of companies. According to show organizer Phil Cieply, the conference drew over 1200 attendees, which is impressive when web-based information sourcing is so dominant and the tech sector is still emerging from a major slowdown.
OS and embedded software panels
Given my emphasis towards Open Source and embedded software, I attended the following two embedded system panels:
Linux and RTOS in Distributed Systems, hosted by analyst Tom Williams.
Selecting an Embedded Operating System: A Client's Perspective, hosted by Brian Mendel of Boeing Phantom Works.
Both panels were reasonably well-attended. Each panel member had a presentation, which was followed by an audience participation session. Unfortunately, the panel hosts should have been stronger participants in their own events, as the unrestrained panelists presented sales infomercials rather than unique technical or industry viewpoints. Moreover, the presentations were too long, and thus little time remained for audience questions or meaningful discussion.
The Linux and RTOS panel
The first panel focus was that both Linux and traditional RTOS platforms can exist in multi-tier embedded designs. Examples include communications equipment structured with distinct management and control/data planes, where Linux hosts management applications, and a combination of Linux and RTOS support blade or line-card applications.
Panelists from Wind River Systems (VxWorks RTOS) and Enea Embedded Technology (OSE RTOS) aptly positioned their own Linux offerings in this context, by striving to retain room for their RTOS in a space increasingly dominated by Linux and other Free and Open Source Software (FOSS) components.
Metrowerks partners with traditional RTOS and embedded Linux suppliers (and inherits Linux platform tools from Lineo). They therefore took an expected neutral stand by echoing other panelists' call for tools that address both operating systems in a mixed environment.
Linux and Open Source debate
Much less amenable to useful coexistence was Dan O'Dowd of Green Hills Software (INTEGRITY RTOS). Rather than respond to the panel host's call for commentary on the balance between Linux and RTOSs, Mr. O'Dowd chose to use his panel slot as a forum for a public discourse against Linux and its embedded application. In my opinion, he made numerous questionable and misleading statements about Linux and Open Source.
Since most of Mr. O'Dowd's arguments build on common misconceptions about Open Source Software (OSS), they merit closer examination.
Footprint - Is Linux too big for embedded?
Mr. O'Dowd compared Linux to a Mac truck attempting to compete at Le Mans. Certainly, full-blown enterprise Linux and fully-outfitted embedded Linux configurations can produce multi-megabyte system images. However, no one ever asserted that Linux was a Formula Racer.
Linux was designed to tow heavy loads and still perform - something team Ferrari need not worry about. Also, unlike the minimal RTOS software of Mr. O'Dowd's reference, Linux provides a stable and complete platform that is ready to run an enormous array of COTS software.
By contrast, RTOS systems are built selectively from libraries, where each deployment only draws on the routines actually required by the application. If an RTOS like Green Hills INTEGRITY were configured to match the Linux basic capability set, its footprint would run to many megabytes, and actually be larger than that a comparable Linux system footprint.
Real-Time - Can Linux meet real-time deadlines?
Linux is not an RTOS. It was not designed for full pre-emptibility, or to offer the most rapid interrupt response times. Instead, it was designed for robustness and throughput.
Industry studies and real-world experience shows that 90% of all embedded applications do not have hard real-time requirements. Moreover, 87% of respondents to a VDC study of embedded Linux found that Linux fully satisfies their real-time needs. Certainly there exist numerous applications that need traditional hard real-time. And a large portion of such applications fall into the aerospace and defense arena that RTOS companies target.
But even traditional aerospace and defense applications, to say nothing of thousands of projects in consumer electronics, networking, telecommunications, instrumentation, and control are choosing embedded Linux instead of RTOS.
Standards - Is Linux standards-compliant?
In a word - yes. Linux, like the other UNIX-type operating systems, is POSIX compliant by definition. That is, it implements a large subset of one of the dozens of sub-standards that fall into the IEEE 1003 family for OS definition.
It is not fully conformant to any one of those subsets (e.g., what used to be called POSIX.1 - UNIX OS definition, or POSIX.1c, threading), in that Linux does not pass all suite tests such as the Open Group or original NIST suite tests. In some cases, the Open Source community has not invested the time in creating conformant APIs and behaviors. In other cases, Linus Torvalds and others have made conscious decisions to avoid the awkward constructs and overly complex semantics that POSIX predicates.
Beyond POSIX, Linux and its application stack offer developers a veritable alphabet soup of standards compliance such as:
BSD
CORBA
Java
NFS
OSPi/BGP/RIP Perl/PHP
SMB
SSL/SSH
TCP/IP (IPv6)
X11
Furthermore, many assert that Linux itself constitutes a viable standard, or at least an emerging one. Certainly more code has been created for and ported to Linux than any for proprietary OS or RTOS, including those that do pass the vaunted POSIX conformance tests.
Support - Does first-tier support exist for Linux?
Proprietary RTOS companies do provide a very direct type of support - they create their own code and then (usually) support it as part of their business model. Embedded Linux companies, however, contribute to a community code base, and also support the code developed outside their walls.
The proprietary develop/support model proves challenging to sustain in real life: companies purchase each others' IP, phase out product versions, and habitually end-of-life whole product lines, leaving customers stranded.
Even when long-lived companies offer long-term support for their products, the team that actually produced the code is typically not the team that supports it. In most companies past start-up stage, the developers that produced the code have long since departed by the time you purchase it. In addition, at any point in a product life cycle, most proprietary software companies cannot afford to dedicate significant resources to technical support and continual engineering.
Not so with Open Source Linux. Any given piece of Linux or other OSS code is a shared resource, and will therefore have dozens or even hundreds of companies that provide support for it. There are even mailing lists for help with most projects, and you can obtain support for Linux 2.6 and prior versions. And, unlike most proprietary software, you can maintain Linux yourself.
Licensing - Does GPL-licensed Linux force OEMs to open their IP?
The GPL (General Public License) for the Linux kernel source code obligates developers who redistribute binaries derived from GPL code to accompany those binaries with source (and a copy of the GPL license).
Developers, ISVs, and embedded device OEMs can and do retain control of proprietary IP in application code, libraries, middleware, and even device interface code.
Just ask BMW, Cisco, D-Link, GE, HP, IBM, Intel, Motorola, NorTel, NTT-DoCoMo, Panasonic, Philips, Samsung, Sony, Yamaha, and hundreds of other Global 1000 companies that build their devices and infrastructure with Linux.
Development - Is open source development disciplined or ad hoc?
Traditional proprietary RTOS code is developed by a small cadre of engineers under great pressure to meet product market deadlines. Because most code consumers will never actually be able to browse through the source, proprietary kernel and OS code quality can vary widely. So can the discipline that governs its creation, including design methodology, coding standards, code review practices, and quality assurance.
By contrast, Open Source Linux and its development practices are highly transparent. For better or for worse, the whole world can inspect the code, examine the practices used to create it, and via attribution even know the pedigree of each engineer contributing to it.
Just because the Linux and OSS base is large does not mean it lacks structure and discipline. Just within the Linux kernel, there are distinct teams that maintain subsystems like memory management, the virtual file system, the scheduler, and the distinct interfaces like USB or PCI. The maintenance teams selectively accept contributions from qualified community members and make their own contributions, and then must petition the top-level kernel maintainers (for instance, Linus Torvalds) for acceptance on merit, style, and code quality.
The Open Source development process is so well disciplined that it has integrated and quality-assured contributions from thousands of developers in dozens of countries.
The embedded OS selection panel
The second panel proved almost as contentious as the first. Despite its focus on embedded OS selection for aerospace and defense applications - an area not currently well served by Linux - the panelists included representatives from embedded Linux vendors MontaVista and TimeSys, dual-OS supplier Wind River, and Linux consultant Doug Locke. It also included Mr. O'Dowd of Green Hills Software and his views against the adoption of embedded Linux.
Once again, the panel leader could have done more to drive the panel and to cut short yet another round of vendor sales presentations. Too little time remained for meaningful interaction, and the dialog that did occur steered predictably back to the questioning of the viability of embedded Linux by the traditional RTOS-consuming audience.
What disturbed me most was that the embedded Linux advocates on the panel were unprepared to meet this barrage of criticism and tough questioning. Unfortunately, most of Mr. O'Dowd's assertions and the audience's concerns about Linux went unchallenged and unanswered. The advocates were unprepared even after current analyst reports indicate that Linux is now the number one embedded OS.
There are days when I wonder if the success of embedded Linux really comes from our efforts, or occurs in spite of them. This was one of those days.
. . . . .
Bill Weinberg brings over 17 years embedded and open systems experience to his role as Open Source Architecture Specialist at the Open Source Development Labs. Bill can be contacted at bweinberg@osdl.org.
OSDL – home to Linus Torvalds, the creator of Linux – is dedicated to accelerating the growth and adoption of Linux in the enterprise. Contact the OSDL directly for membership and lab usage information.
Open Source Development Labs, Inc.
12725 SW Millikan Way, Suite 400
Beaverton, OR 97005
Tel: 503-626-2455 • Fax: 503-626-2436
Website: www.osdl.org
