A developer’s review of Red Hat’s Embedded Linux Developer Suite (Part 2)
Nov 27, 1997 — by LinuxDevices Staff — from the LinuxDevices Archive — 1 viewsConfiguring the system
Having set up the project, we then move to configuring the system. To do so you run the main program of the ELDS user interface, improbably named “pconf3.py”. This program could serve as a textbook case on how not to design user interfaces.
The user is presented with five choices, none of them greyed out, plus an exit button. One might expect that any of the five would be a valid choice, but if you click the “Package Configuration” button before the “Build Kernel/SRPMS” button you are greeted with an error box saying something cryptic about “MANIFEST”. So you must “Build Kernel/SRPMS” first.
Like MontaVista's Hard Hat, Red Hat's ELDS makes use of the standard “make xconfig” facility for kernel configuration. In my review of Hard Hat, I expressed some reservations about this choice because it breaks up the unity of the user interface; for example, Hard Hat finds it necessary to instruct the user to ignore a message (instructing the user to 'make dep') generated at the end of “make xconfig”, producing a distracting effect. But the way ELDS handles integrating the xconfig facility makes my comments about Hard Hat seem positively quaint. The extraneous xconfig message is also present in ELDS, but ELDS does not even bother to instruct the user to ignore it — it's just out there with no explanation whatsoever. And the documentation provides no help with xconfig. The manual dismisses us by curtly commenting that kernel configuration is “outside the scope of this documentation”, providing only a link to some general Linux documentation. I'd like to know what Red Hat considers to be within its scope.
Every window launched by “pconf3.py” is titled “Embedded Linux Developer Suite”. Also, the windows are all modeless, so you can open any or all of them at once, and work in them in any order (though only a few orders actually make sense). These two factors result in a rather confusing desktop. I explored the environment first, opening windows and then minimizing them when finished with each. For the sake of clarity I will call one of the windows “Package Configuration” after the button I pressed to get to it, though of course the window itself was titled “Embedded Linux Developer Suite” like all the others. At any rate, when I was finished building the kernel and the packages I progressed to the “Package Configuration” screen, having forgotten I already had one copy of that window opened. Rather than simply activate the window I already had opened, ELDS launched another copy. I then realized my mistake, closed the second window, and reactivated the first. But starting the second copy had changed some internal program state, and clicking any button in the first copy then resulted in obscure Python errors. The only way to recover was to restart “pconf3.py”.
Additional “interesting” user interface design decisions are found in the “Meta Configuration” option of pconf3.py. The term “meta configuration” suggests little to me in the context, but clicking this option brings up additional options with a vaguely network tilt, so apparently to Red Hat it means network configuration. In subwindows you can set up your console device, use an NFS-mounted root filesystem if desired, and set up network defaults. Red Hat's penchant for unhelpful window titles is taken to its ludicrous conclusion here. Not only are all the “Meta Configuration” subwindows labeled “Embedded Linux Developer Suite”, but each also has a helpful subtitle to distinguish it — “Meta Configuration” in each case! Finally, although thousands of windows have been successfully implemented over the years with buttons labeled “OK” and “Cancel”, Red Hat has chosen to improve on these options with “Save Status” and “Close Window”. Don't worry; ELDS users will get used to these eventually.
I could continue in this vein somewhat longer, but you probably get the idea. An amusing project would be to draw up a list of important user interface design principles, then throw away those that ELDS violates — I think very few would remain. In countless ways — some major and some minor — the ELDS user interface is guaranteed to annoy any user. One may argue that these front end issues are unimportant; the real work of ELDS is on the back end. That may be true; but the back end of ELDS is Linux itself, for which Red Hat cannot take credit. Assembling a working embedded system from the various Linux and GNU tools is not that difficult for an experienced Linux developer. So an Embedded Linux toolkit vendor had better focus on an easy to use front end to make the experience palatable to beginners. A properly designed user interface to ELDS would not have taken much extra effort to implement; one wonders why Red Hat didn't bother.
Selecting and configuring packages
Packages to be included in the target system are specified in the “Package Configuration” screen. This screen is organized in a way quite similar to that of MontaVista's Target Configuration Tool (TCT). The packages are organized into categories — “System Environment (Shells)”, “Applications (File)”, and “Development/Debugging”, to cite a few examples. Individual packages are listed under these categories — for example, “ash”, “bash”, and “sh utils” under “System Environment (Shells)” — which each correspond to a source RPM file. ELDS has an additional layer of selectivity, corresponding to optional features within each RPM. The 'iputils' package, for example, can optionally load the IPV6 utilities ping6, traceroute6, and tracepath6.
Like MontaVista's TCT, the “Package Configuration” screen lacks defaults; when first started, nothing is selected, not even capabilities found in most embedded systems. But when you save the resulting configuration file, ELDS checks for completeness, offering you the option to add those capabilities needed to make the system consistent. So to start working with reasonable defaults, enter “Package Configuration”, immediately save the .config file from the “File” menu, and accept the suggestions ELDS offers before saving. At this point your build has typical capabilities, and you can add to or subtract from them to meet your application needs.
Also like TCT, “Package Configuration” lacks searching capabilities. So, for example, you will have to guess that /etc/exports is under “Setup” rather than “nfs utils” or elsewhere, or spend some time clicking around to find it. One sign that you're dealing with an unfinished graphical interface is when you find yourself dipping into the underlying environment to accomplish what you need done. Indeed, I quickly started calling up into vi the “book2.xml” file which defines the categories used by “Package Configuration” and performing searches there to find out where packages are. This works well, but if you are looking for individual files you will have to combine this approach with grepping through the XML files defining the files in each package.
Thus, for example, suppose you decide you need the “shutdown” utility, but don't know offhand that it is part of the SysVinit package; and even if you knew its SysVinit origin, you don't know that SysVinit is categorized under “System Environment (Base)”. You can grep the XML files for the string “shutdown” to determine that the file is defined in SysVinit (doing an “rpm -qf /sbin/shutdown” on your RPM-based host might provide the same information). Then search book2.xml for SysVinit to find its category. Finally you can go back to “Package Configuration” to actually select “shutdown”. All of this works, but how it is an improvement over some simple but well-documented command-line interface escapes me.
Story navigation . . .
- Part 1: Toolkit strategies
- Part 2: Configuring the system
- Part 3: Building target images for three SBCs
- Part 4: Overall assessment
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.