Dr. Dobb's Journal - June 2008 - (Page 23)

d06doug_p4db 4/11/08 9:44 AM Page 23 (including altivec support), PowerPC 4xx, PowerPC 8xx, PowerPC e500, FRV, MIPS, and ARM/XScale, we end up building an entire toolchain and root filesystem for a number of architectures. The system then builds the Linux/BSD kernels (we have about 25 different source trees that need to be built), RTCore (the realtime kernel), and all real-time drivers and add-ons to RTCore (real-time networking, memory protection, interfaces, and so on). While the builds run, they show “in progress” on the web page. Once complete, they display success/failure and are colorcoded appropriately: blue in progress, red failed, and green success. When the entire build test for a given architecture is complete, the Linux, NetBSD, or FreeBSD kernel is copied to the tftp boot file location on our server, the root filesystem for the tests is copied to the NFS server, and the build for the next architecture/configuration is started. While the next build continues, the current tests commence. Every test starts by booting a given board that has been put on our test rack. We centralize this information in the board.sh shell script, which lets each platform be referred to by a specific board name or platform—“Opteron 64bit SMP” or just “host114.” Board.sh is called by the test system to start logging the serial console output and reset power on the board. Once this stage is complete, we know the compiler tools have produced a working and booting Linux/BSD kernel, NFS root works, and compiled healthy user utilities. The test system then runs some standard tests that all platforms must pass—about 350 in all. They test for the presence of previously fixed bugs, ensure the system conforms to our software specification documents, and test the general health and functioning of the system. The tests run a total of 15 iterations. The next set of standard tests is measurement tests (see devnet.developerpipeline .com/documents/s=9854/q=1/cuj0404dougan/ 0404dougan.htm) that verify that performance is within expected tolerances for each platform and ensure that we have a consistent source of benchmarks. We often use those to verify that feature creep has not affected system performance—which lets us study long-term trends in our system months or years later. Because not every test can be run on every platform and sometimes the tests require multiple hosts, we encode that information in the shell script itself; for example, if the platform ppc_gemini is the only one that can run this test, yet two hosts are required. Figure 1 illustrates the results during a build with some failures, some successes, and some in-progress. Hardware and Technology for Testing Again, our software is based on the operating system RTCore, which runs the bare hardware and lets other nonreal-time operating continued on page 26 Figure 1: Status web page (partial). June 2008 l www.ddj.com l Dr. Dobb’s Journal 23 http://www.leadtools.com/dobbs http://www.leadtools.com/dobbs http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - June 2008

Dr. Dobb's Journal - June 2008 Contents Friday Night Fish Fry Alia Vox Developer Diaries There Must Be Contest Conversations Building a Test Harness for RTOS QT and Windows CE Software to Hardware Parallelization Performance Portable C++ Effective Concurrency The Agile Edge Swaine's Flames

Dr. Dobb's Journal - June 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.