News Archive (1999-2012) | 2013-current at LinuxGizmos | Current Tech News Portal |    About   

Article: A developer’s review of Qplus, an open source embedded Linux toolkit

Nov 25, 2002 — by LinuxDevices Staff — from the LinuxDevices Archive — 6 views

Background

Previous articles in this series have examined some commercial toolkits available for embedding Linux. The products from Lineo, MontaVista, target=”new”>Red Hat, LynuxWorks, and REDSonic aim to replace proprietary embedded operating systems with Linux, though all use some proprietary tools themselves.

The pure open source options for embedded Linux toolkits have been few in number, perhaps because constructing a usable system from scratch using the freely-available sources is not difficult for an experienced Linux user, or one with some time to invest in learning how. But there is a real need for an open source toolkit that would:

  • help new users get started
  • provide tools to integrate kernel and root filesystem configuration
  • serve as a repository for open source packages important in embedded systems
  • establish a standard for the definition of embedded Linux board support packages (BSPs)

Qplus, provided by Woochul Kang and Heechul Yun of Korea's Electronics and Telecommunications Research Institute (ETRI), holds considerable promise on all these fronts. Qplus is already a remarkable product even in its initial release under the GPL. This article takes a look at the toolkit in some detail, examining what the Qplus project has accomplished, and what is still to be done.

Initial impressions

For an early-stage open source project, Qplus is remarkably full-featured. It consists of Target Builder, a GUI front end for defining and constructing targets; a CML2-based back end that integrates the configuration of kernels, root filesystems, and deployment methods; a library optimization tool; and a few BSPs for x86 and ARM targets.

I found Qplus to be admirably agnostic about the cross-development system Linux distribution you use. It specifies Red Hat 7.0 through 7.2 and something called WowLinux 7.1 (a Korean distribution), but users of x86 RPM-based distributions should have no trouble. And I had little trouble installing it on my Debian 3.0 system, as it only required initializing the RPM database using the –initdb flag. I also had to create a link from /usr/lib/libbz2.so.1.0 to /usr/lib/libbz2.so.1 for the benefit of a prebuilt binary /opt/q_esto_tc/rpm/lib/rpm/rpmb. Finally, the deployment stage is necessarily somewhat dependent on the host distribution, as we shall see later.

Target Builder itself is a quite well-designed and usable GUI even if judged by commercial toolkit standards — truly a remarkable accomplishment for an early-stage open source project. Target Builder requires Python 2.2, as it uses wxWindows. Python 2.2 is not yet included with many distributions, so the project helpfully distributes it with Qplus itself. Most other needed tools are included as well, so a complete installation of Qplus along with any normal desktop Linux distribution ought to get you started.

Like some of the other products reviewed in this series, the entire project is viewed as a tree of configuration options, split into subtrees for the kernel, the root filesystem (called “System Configuration”), and target configuration (for target network configuration, library optimization, and system deployment options). Configuring the system is a matter of visiting those nodes of the tree that need to be changed and selecting the right options.

Qplus is one of the better-organized products reviewed in this series. It provides reasonable defaults for all options, and I found the positioning of the options within the tree quite intuitive — more than can be said for some of the other products reviewed here. A search function for finding options is provided, including searching the help text. The process of building the components is integrated into the GUI in a seamless way. In general, I found the Qplus GUI to be comparable in usability to the best of the proprietary tools — truly this is one stunningly unusual open source project.

One could quibble with some aspects of Target Builder. For example . . .

  • Like some of the other products reviewed in this series, it sends some of its output to the shell from which it was run rather than to the GUI itself.
  • Also, its handling of long-running operations is less than optimal. Rather than displaying the status of the operation in the GUI, Target Builder sometimes merely freezes while the operation is running — you have to go look at the shell to find out what is happening.
  • Finally, the search facility, essential for configuring the kernel and system, is case-sensitive — not a good choice.

It need hardly be pointed out that these minor issues are considerably easier to forgive in a free software package than in one for which you must pay thousands of dollars. And these simple issues are sure to be ironed out quickly as the project gets wider developer attention — indeed, Heechul Yun reports the handling of long-running processes is already nearly fixed as of this writing.

A look under the hood

A look under the Qplus hood also reveals some good design decisions, although one may prove to be unfortunate.

As mentioned, Qplus uses CML2 as the back end of its configuration system. You may be familiar with CML2 as the framework proposed by Eric Raymond to replace the current Linux kernel configuration system. Depending on whom you ask, CML2 is either an elegant and flexible general-purpose tool for configuring systems, or a needlessly complicated system provided for the ego gratification of a language freak and self-anointed “hacker of social systems”. The opinion of the kernel developers was closer to the latter, with the result that CML2 was rejected for inclusion in the kernel.

This rejection could prove unfortunate for the maintainability of Qplus, as it uses the CML2 language for specifying all of its configuration options, and in particular the kernel. One of the primary challenges facing a vendor of an embedded Linux toolkit is how to integrate the configuration of the kernel with that of the rest of the system. This challenge is complicated by two factors: the peculiar stock Linux kernel configuration system, which few beginners find intuitive; and the rapid pace of Linux kernel development, requiring that any replacement for the stock configuration method be easy to maintain. An embedded Linux toolkit vendor wishing to draw users from the established RTOS vendors must find a way to make kernel configuration easier. But a wholesale replacement of the stock method may be unwise because the replacement would require constant maintenance as Linux evolves.

Thus the embedded Linux toolkit vendors have considerable interest in the kernel developers moving toward a better configuration system. The Qplus developers chose CML2 for configuring everything, a sensible choice both because it works and because earlier this year it appeared that CML2 would be used by the kernel developers. Kernel configuration was then in a limbo for several months as CML2 had been rejected, but no alternative to the previous system had been selected. Linus has recently selected Roman Zippel's elegant and simple configuration system. It seems clear that Qplus must adopt the new scheme in order to maintain the ability to configure the kernel within their system over time — CML2 will presumably not be maintained. On the other hand, CML2 may continue to be a good choice for configuring the rest of the system, so perhaps Qplus will maintain two configuration schemes, unwieldy as this may seem. The upshot of all the political wrangling regarding kernel configuration is that the Qplus project will probably have a lot of work to do as the kernel picture becomes clearer.

In any case, the CML2-based configuration model implemented by Qplus is currently well thought out. The kernel part uses the standard CML2 patch in a straightforward way. Package selection and configuration is done with a hybrid CML2/RPM scheme using something called QPD files. These are simple extensions to the RPM spec file to allow greater per-package configuration. This allows you to specify options to be used when the package itself is configured. This is especially useful, for example, for configuring flexible packages like BusyBox. The busybox.qpd file contains “%option” entries for each of the tools busybox can provide. So the %option entries for “ash”, “lash”, “hush”, and “msh”, for example, specify the CML2 symbol names associated with each of these options, and indicate (via the “%%provide” statement) that each of them provides the “shell” capability. Qplus provides a tool to convert QPD files into CML2 statements to be used by Target Builder.

All of this is integrated seamlessly into Target Builder. Integrating a new package consists of placing the SRPM and QPD files in the proper places, then restarting Target Builder. So adding a new package, if you have an SRPM file, is little more than a matter of defining the QPD file for it — and if you have the package's original RPM spec file you've got a head start.

The QPD scheme, and its integration with the well-designed Target Builder, is remarkable in its utility, simplicity, clarity, and efficient use of the pre-existing RPM and CML2 systems. Other systems, such as Lineo's, provide substantially the same capabilities, but use proprietary tools for some or all of their functions, thus excluding open source developers.

Taking it for a spin around the block

Meanwhile, I found support for deployment to generic x86-based targets to be complete and well-documented, if somewhat manual in nature. For network booting, Qplus uses Etherboot, a flexible system that allows you to boot a system from floppy or CD-ROM, then load a kernel and root filesystem from a server on the network. This is especially useful in a cross-development environment as you can build images on your cross-development host and immediately test them on the target. Support for booting from numerous network cards and chips is provided by rom-o-matic.org; this site generates a boot image for you based on your choice of network and boot hardware. Having created a target boot disk, you have to set up your development computer with DHCP, TFTP, and NFS. This is probably the most distribution-specific aspect of Qplus use. The documentation describes the process well for Red Hat systems, but other distributions will have minor differences, especially in configuration file locations.

The supported modes of deployment are initrd, in which the kernel and root filesystem are loaded into and remain in RAM; NFS-mounting the root filesystem, which is especially useful when developing application code as you can simply change files on your development machine, then test them on the target; and installing the kernel and root filesystem directly on the target, which is the last step of the cross-development process. Qplus then provides an rsync-based mechanism to synchronize the target system with changes you make on your development host.

Deployment to the three x86-based SBCs (from Ampro, Winsystems, and Adastra) I'm using for this series was straightforward, after making some changes due to my using an unsupported (Debian 3.0) platform. The Qplus documentation assumes the use of xinetd (Red Hat's default); I simply had to edit the inetd.conf file on my Debian system to support tftp connections. Presumably one could also simply use Debian's xinetd. I also had to install, configure, and start Debian's dhcp and nfs servers, both of which are packaged somewhat differently from Red Hat's.

After I made these adjustments, deployment went smoothly, with one exception. I first configured and built the kernel with the default processor type (Pentium III); then realized my mistake (the SBCs are all Pentiums), changed the kernel configuration in the GUI, and rebuilt the kernel. But the SBCs immediately crashed as soon as control was transferred to kernel. It took some head-scratching before I realized the kernel still had Pentium III instructions compiled in. The “Build Kernel — Force” GUI action should probably do a “make clean” before recompiling to ensure that a full rebuild occurs when the configuration is changed. Like the GUI issues mentioned earlier, this is a minor issue and easily fixed.

Requirements for success

The Qplus-P Target Builder User's Guide is exceptionally well written, especially for the documentation of an open source project. As of this writing it is incomplete, but already contains all one needs for most uses of Qplus. It could stand a review by a native English speaker, but is nevertheless quite understandable. I find it amazing that such an early stage open source project has a usable manual at all, much less one that provides substantially all one needs to use the system.

Also provided is a brief guide to putting BSPs together — this is important as the success of Qplus will depend on board vendors and users contributing BSPs to the project

Not surprisingly, some parts of Qplus are not quite complete. As I mentioned, the manual is not finished, specifically missing board-specific sections. Also incomplete is the library optimization facility. A simple but useful file-level optimization is provided; this examines the executable programs and shared libraries in a build, then removes those shared libraries not needed by the executables. A further symbol-level optimization is planned, but not yet complete. This more complex process would eliminate from shared libraries those symbols not referenced in an executable.

Until recently, the Qplus project lacked a hosting site. However, the project has recently become hosted at SourceForge, at sourceforge.net/projects/qplus, and additional information is available here. Additionally, LinuxDevices.com is making the Qplus documentation file available for download, here (1.9 MB pdf download). [Please note that the file may not be readable with Adobe Acrobat due to unsupported Korean characters (without the addition of some sort of Korean language support module), whereas it appears to be readable using xpdf.]

The introduction of Qplus is certain to be a welcome development for developers who have been hoping for a pure open source embedded Linux toolkit. It is already an impressively capable kit, with suitably ambitious goals and a well-designed infrastructure to achieve them. A few challenges stand in the way of its widespread success . . .

  • Project infrastructure — First and most obvious, it needs hosting and the normal infrastructure of an open source project, including a home page and mailing list. It is amusing to compare Qplus, having a complete set of software and documentation but no project infrastructure, with the mass of Sourceforge projects fully prepared with infrastructure but having little code to show.
  • Uncertainty of CML2 — the designers' choice of CML2 as its basis is defensible, but this decision has become a victim of the decision by the kernel developers to reject CML2. Maintaining the CML2 kernel rules will be impractical in the long run, so Qplus will have to switch to using the standard kernel configuration system. There is probably no need for immediate action — such a switch should wait until the new kernel configuration scheme stabilizes. In the meantime, sticking with the 2.4 kernel with CML2 rules is perfectly acceptable.
  • BSPs — Perhaps more important is acquiring the critical mass of BSPs necessary to gain widespread acceptance. The proprietary toolkits already have an impressive array of BSPs for various SBCs and other platforms. This is important to customers who need to know that their application is not fixed to one platform, but is portable to a number of others that are BSP-supported. Arranging for the development and support of BSPs is one of the things commercial organizations, with their marketing and engineering capabilities, are well prepared for. But an open source project must rely on users to develop BSPs when they have a need for them, and to fix bugs in them when needed.

The open source model can work — witness Linux itself, which has developed the critical mass of device drivers needed for widespread acceptance. Whether this model can work in the embedded system world, which is populated less by do-it-yourself hackers and more by professionals simply looking for a platform on which to deploy their applications, remains to be seen. But the Qplus developers have provided a fine attempt at making it work.

About the author: Jerry Epplin has written embedded software for the past fifteen years, primarily for medical devices.

.

Also, be sure to read the other articles in this series by Jerry Epplin . . .

 
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.

Related Posts:



Comments are closed.