The SPARC Port of Linux

Summary by Gordon Galligher

This was the first session in the USELINUX Developers track at the conference. David and Miguel went into specifics on what problems they ran into when trying to port Linux from the reference port (Intel hardware) to the SPARC-based hardware. David spent most of his time on the actual porting efforts in the kernel. Miguel worked on making sure that the libraries, and especially libc, were "clean." This resulted in the bulk of the system being ported as easily as recompiling the individual programs on the new hardware.

It was slow going at first: David was able to get a "hello, world" program to print in the boot PROM monitor fairly quickly. It was six or seven months later before he was able to present the user with a shell prompt. They then worked on getting SunOS binaries to run under SPARCLinux. A representative of RedHat approached them to take their work and build their customized installation format around it to make it very easy for people to install.

Required Kernel Changes. Many kernel changes were necessary to make SPARCLinux work, mainly because there was a significant amount of Intel code embedded in the original Linux kernel. At the same time they were working on the SPARC port, Linus Torvalds was working on the DEC Alpha port. As a result, much of the "cleanup" work that each of them ended up doing made it easier for the other in the long run. The kernel was very "endian" specific, with a number of assumptions made about the "endian-ness" of the hardware.

David could have made a "big-endian" version with a number of #ifdef statements in the kernel code; but instead he realized that it might be useful to take disks from one Linux system directly onto another-just plug and play. In order to do that, the actual layout of the file system had to be consistent and could not suffer from the bit swapping of the endian problem. David wrote macros that are used in the filesystem code so that the filesystem layout is identical on the SPARCLinux and the Intel Linux ports. This limits the places for the #ifdef sections to only the headers where those macros are defined.

Much time was spent analyzing and optimizing the entry and exit points for the kernel. A major design goal was to make the SPARCLinux port very usable and fast. Other efforts were spent making the various checksum and memory copy routines as efficient as possible, because the bulk of the kernel work involves copying of data to and fro.

Library Issues. Much care was put into making the libraries, especially libc, as consistent as possible. This made the effort of porting other applications and system routines as easy as a recompile. One system routine, however, could not be ported easily: fsck. This application was written predominantly in assembler for speed, and that just does not port easily. It required a rewrite in order to work on SPARC-Linux. The libc is based on H. J. Lieu's version, but there are plans to move to the GNU version, which provides more functionality.

Furthermore, a definite goal is to have shared libraries that take advantage of the specific features of new hardware (i.e., hardware multipliers instead of emulation, etc.). It is possible to implement this now, but it would not be a "clean" implementation, esthetically speaking, and would require a considerable amount of specifying in the various header and program files. Miguel is continuing to work on specifications for a clean version.

Future Efforts. One of the future efforts of SPARCLinux is to get Solaris binaries to work native to the OS. Most of the SunOS binaries work without incident, but Solaris binaries continue to have problems when trying to dig into the kernel. Another large effort is to make the OS as efficient as possible. An ideal case is to get each system call to take only as much time as a regular procedure call. This effort has resulted in getting the architecture-specific context switching down to only 17 instructions. This is a tremendous performance win, considering that the Solaris kernel can do only as many as 500 context switches in a second because of the overhead.

There is also work in making the system calls "intelligent" in that they do not copy the arguments, but merely put them on the stack-i.e., using the same ABI convention as the subroutines. The Solaris kernel does it this way, and it is desired that SPARCLinux do it as well. There was one thing that concerned me during David's talk, however, and it was when he mentioned that he has done a specific optimization that "requires" the GNU C Compiler in order to work. There were no specifics given as to what routine had this requirement, but it was mentioned.

Stability. The crashme program is a good program to randomly insert data where one would not think it would show up. As an example, David did see it pass a single byte down a socket at one point, and the application program choked on it. However, he has been successfully running crashme from the init process on his personal workstation, and it has remained very stable.

Questions/Answers. This was, arguably, the most fun part of this talk. David came up with a number of questions that "opponents" of SPARCLinux typically throw at him, and then he responded to them. One of the questions he posted dealt with having a single kernel to support all of the various SPARC architectures (as opposed to the way that SunSoft has different kernel architectures requiring different kernels and different compiled routines). David's response: "Oh Really? Ask the users if they want to remember the difference [moving a kernel to a new architecture is not as simple as an rcp]. Besides, it is still faster than Solaris!"

My favorite question revolved around the scalability of SPARCLinux. David's response was that the more people who use it, the more people who will be interested in making it better and more scalable; thus the scalability issue will go away. His first answer, however, was my favorite: "bite me!"

Reference information. The SPARC port of Linux can be obtained from the following sites:

ftp://ftp.redhat.com/pub/redhat
ftp://vger.rutgers.edu/pub/linux/Sparc
https://www.redhat.com/

Mailing lists about the SPARC port are at the following:

sparclinux@vger.rutgers.edu
sparc-list@redhat.com

Originally published in ;login: Vol. 22, No.2, April 1997.