Readers regularly request that we give updates on the progress being made porting Linux to other platforms. We are happy to comply; it's a wonderful opportunity to show off Linux's impressive progress...
by Michael K. Johnson
In the last few months, SPARCLinux has gone from starting to run a few binaries to being stable on a supported single-processor and multiple-processor SPARC machines. Not only that, but supported SPARC machines include a SPARC-based supercomputer, the Fujitsu AP1000+.
David Miller, at Rutgers University, started the port about a year ago. Within a few months, other developers joined the project, and now the team includes several talented Linux Hackers from around the world, such as Miguel de Icaza from Mexico, Peter Zaitcev from Rumania, and Paul Mackerras, David Walsh, David Sitsky, and Andrew Tridgell from Australia. In addition, Ross Technology, a manufacturer and vendor of SPARC hardware, sent high-end hyperSPARC processors to David in order to help the port along.
The SPARCLinux kernel is remarkably stable; David now requires that every kernel pass a “crashme” test (see Crashme, below) for about 24 hours before releasing the source code for it. The kernel also performs well, benchmarking better than both SunOS and Solaris in almost all tests that have been done so far. It also provides strong binary compatibility with SunOS, and binary compatibility with Solaris is in the works.
Unfortunately, a SPARCLinux distribution is not ready yet, and if you want to actually use SPARCLinux, it is like a trip into Linux history, gathering binaries from different sites to get enough programs to actually use it. Even when those binaries are collected, the resulting systems is not particularly stable or complete—not because the kernel itself is unstable, but because the user-level programs aren't yet up to snuff. And the bootstrapping process of getting a Linux system installed is not yet simple.
Fortunately, Red Hat Software is working with the SPARCLinux developers to create a Red Hat Commercial Linux for SPARC, and they make their ongoing work available from their web site (www.redhat.com) and their ftp site (ftp.redhat.com). As of this writing, about 70 RPM packages are available for SPARCLinux. While Red Hat works on providing a set of stable user-level programs, Miguel is working on providing a stable set of shared libraries for them to base those programs on.
SPARCLinux currently supports most SUN4c (SPARC 1, 1+, 2, IPC, IPX, SLC, ELC) and Sun4m (SPARC Classic, LX, 5, 10, 20) machines. HyperSPARC machines are supported in single-processor and multi-processor modes.
Others, including sun4d (SPARCCenter 1000/2000) and the old sun4 architecture aren't supported yet. Contact David if you can help with these or provide hardware, especially sun4d machines (donations and loans are both accepted...). The sun4u work is underway but not finished yet.
The crashme program tries to do what its name implies: it tries to crash the computer on which it is run. It does this by creating “random” data and then trying to run that data as executable code. This causes it to do things that the designers of the operating system never thought about, and finds security holes and operating systems bugs that don't seem to show up reliably in any other way—except while running buggy programs. The difference is that crashme logs exactly what it does and creates its “random” data in exactly the same way each time it runs, making it possible for developers to duplicate—and therefor fix—the bugs that crashme finds.
Few commercial versions of Unix survive crashme for more than a few minutes. Linux, including SPARCLinux, survives running many instances of crashme at once for days on end.
As many of you know, most of the Linux mailing lists are maintained on a machine called vger.rutgers.edu. Vger is a SPARC currently running SunOS. David's personal goal is to run Linux on Vger, as this will provide another stress test besides crashme to ensure that SPARCLinux is very stable. Besides, it seems more appropriate to run the Linux mailing lists on a Linux machine.
One of the mailing lists on vger is sparclinux@vger.rutgers.edu, which is where the SPARCLinux developers hang out. The list is currently fairly quiet, with only a few messages most days, but this may change by the time you read this article. In addition, there are a few invaluable URLs for more information on SPARCLinux, including:
David has promised to write a series of Kernel Korner articles detailing the technical issues encountered while doing the port. He gave an interesting talk at the NCSU Linux Expo 96 in Raleigh, North Carolina, in early April, and we expect even more interesting details from him in his articles. We can expect everything from technical challenges encountered in the porting process to interesting technical details about SPARC architecture.
I've mentioned the Linux Expo—but it was about more than the SPARC port, not surprisingly. Alan Cox came over from Wales to give a talk on SMP (Symmetric Multi-Processing, where multiple processors in the same machine share memory address space) on the Intel platform. David's talk also covered SMP, but on the SPARC platform. There were other “nerd” talks as well, and one very good, but less “nerdy”, talk by Jon “maddog” Hall of Digital. His main point was that there are two ways vendors can use standards:
