0172316072 intro 7/26/99 2:18 PM Page 1 Introduction Linux has always provided a rich programming environment, and it has only grown rich- er. Two new compilers, egcs and pgcs, joined the GNU project’s gcc, the original Linux compiler. In fact, as this book went to press, the Free Software Foundation, custodians of the GNU project, announced that gcc would be maintained by the creators and maintain- ers of egcs. A huge variety of editors stand alongside the spartan and much-maligned vi and emacs’ marvelous complexity. Driven largely by the Linux kernel, GNU’s C library has evolved so dramatically that a new version, glibc (also known as libc6) has emerged as the standard C library. Linux hackers have honed the GNU project’s always service- able development suite into powerful tools. New widget sets have taken their place beside the old UNIX standbys. Lesstif is a free, source-compatible implementation of Motif 1.2; KDE, the K Desktop Environment based on the Qt class libraries from TrollTech, answers the desktop challenge posed by the X Consortium’s CDE (Common Desktop Environment). What This Book Will Do for You In this book, we propose to show you how to program in, on, and for Linux. We’ll focus almost exclusively on the C language because C is still Linux’s lingua franca. After introducing you to some essential development tools, we dive right in to system programming, followed by a section on interprocess communication and network programming. After a section devoted to programming Linux’s user interface with both text-based and graphical tools (the X Window system), a section on specialized topics, including shell programming, security considerations, and using the GNU project’s gdb debugger, rounds out the technical discussion. We close the book with three chapters on a topic normally disregarded in programming books: delivering your application to users. These final chapters show you how to use package management tools such as RPM, how to create useful documentation, and discuss licensing issues and options. If we’ve done our job correctly, you should be well prepared to participate in the great sociological and technological phenomenon called “Linux.” Intended Audience Programmers familiar with other operating systems but new to Linux get a solid intro- duction to programming under Linux. We cover both the tools you will use and the environment in which you will be working.
0172316072 intro 7/26/99 2:18 PM Page 2 Linux Programming 2 UNLEASHED Experienced UNIX programmers will find Linux’s programming idioms very familiar. What we hope to accomplish for this group is to highlight the differences you will encounter. Maximum portability will be an important topic because Linux runs on an ever-growing variety of platforms: Intel i386, Sun Sparcs, Digital Alphas, MIPS proces- sors, Power PCs, and Motorola 68000-based Macintosh computers. Intermediate C programmers will also gain a lot from this book. In general, program- ming Linux is similar to programming any other UNIX-like system, so we start you on the path toward becoming an effective UNIX programmer and introduce you to the pecu- liarities of Linux/UNIX hacking. Linux Programming Unleashed, Chapter by Chapter This is not a C tutorial, but you will get a very quick refresher. You will need to be able to read and understand C code and understand common C idioms. Our selection of tools rarely strays from the toolbox available from the GNU project. The reason for this is simple: GNU software is standard equipment in every Linux distribution. The first seven chapters cover setting up a development system and using the standard Linux development tools: • gcc • make • autoconf • diff • patch • RCS • emacs The next section introduces system programming topics. If you are a little rusty on the standard C library, Chapter 9 will clear the cobwebs. Chapter 10 covers Linux’s file manipulation routines. Chapter 11 answers the question, “What is a process?” and shows you the system calls associated with processes and job control. We teach you how to get system information in Chapter 12, and then get on our editorial soapbox in Chapter 13 and lecture you about why error-checking is A Good Thing. Of course, we’ll show you how to do it, too. Chapter 14 is devoted to the vagaries of memory management under Linux.
0172316072 intro 7/26/99 2:18 PM Page 3 3 INTRODUCTION We spend four chapters on various approaches to interprocess communication using pipes, message queues, shared memory, and semaphores. Four more chapters show you how to write programs based on the TCP/IP network protocol. After a general introduc- tion to creating and using programming libraries in Chapter 24 (including the transition from libc5 to libc6), we cover writing device drivers and kernel modules in Chapter 25, because considerable programming energy is spent providing kernel support for the latest whiz-bang hardware device or system services. User interface programming takes up the next eight chapters. Two chapters cover charac- ter-mode programming; first the hard way with termcap and termios, and then the easi- er way using ncurses. After a quick introduction to X in Chapter 28, Chapter 29 focuses on using the Motif and Athena widget sets. Programming X using the GTK library is Chapter 30’s subject, followed by Qt (the foundation of KDE) in Chapter 31, and Java programming in Chapter 32. For good measure, we also cover 3D graphics programming using OpenGL. The next section of the book covers three special-purpose topics. Chapter 34 examines bash shell programming. We deal with security-related programming issues in Chapter 35, and devote Chapter 36 to debugging with gdb. The book ends by showing you the final steps for turning your programming project over to the world. Chapter 37 introduces you to tar and the RPM package management tool. Documentation is essential, so we teach you how to write man pages and how to use some SGML-based documentation tools in Chapter 38. Chapter 39, finally, looks at the vital issue of software licensing.
0272316072 part1 7/26/99 2:38 PM Page 5 The Linux Programming Toolkit PART I IN THIS PART • Overview 7 • Setting Up a Development System 13 • Using GNU cc 39 • Project Management Using GNU make 53 • Creating Self-Configuring Software with autoconf 65 • Comparing and Merging Source Files 85 • Version Control with RCS 103 • Creating Programs in Emacs 115
0372316072 CH01 7/26/99 2:01 PM Page 7 Overview CHAPTER 1 by Kurt Wall IN THIS CHAPTER • The Little OS That Did 8 • The Little OS That Will 8 • A Brief History of Linux 9 • Linux and UNIX 9 • Programming Linux 10 • Why Linux Programming? 10
0372316072 CH01 7/26/99 2:01 PM Page 8 The Linux Programming Toolkit 8 PART I Linux has arrived, an astonishing feat accomplished in just over eight years! 1998 was the year Linux finally appeared on corporate America’s radar screens. The Little OS That Did It began in March 1998, when Netscape announced that they would release the source code to their Communicator Internet suite under a modified version of the GNU project’s General Public License (GPL). In July, two of the world’s largest relational database ven- dors, Informix and Oracle, announced native Linux ports of their database products. In August, Intel and Netscape took minority stakes in Red Hat, makers of the market- leading Linux distribution. IBM, meanwhile, began beta testing a Linux port of DB/2. Corel Corporation finally ported their entire office suite to Linux and introduced a line of desktop computers based on Intel’s StrongARM processor and a custom port of Linux. These developments only scratch the surface of the major commercial interest in Linux. Note As this book went to press, Red Hat filed for an initial public offering (IPO) of their stock. It is a delicious irony that a company that makes money on a free operating system is going to become a member of corporate America. I would be remiss if I failed to mention Microsoft’s famous (or infamous) Halloween documents. These were leaked internal memos that detailed Microsoft’s analysis of the threat Linux posed to their market hegemony, particularly their server operating system, Windows NT, and discussed options for meeting the challenge Linux poses. The Little OS That Will As a server operating system, Linux has matured. It can be found running Web servers all over the world and provides file and print services in an increasing number of busi- nesses. An independent think tank, IDG, reported that Linux installations grew at a rate of 212 percent during 1998, the highest growth rate of all server operating systems including Windows NT. Enterprise-level features, such as support for multi-processing and large file-system support, continue to mature, too. The 2.2 kernel now supports up to sixteen processors (up from four in the 2.0 series kernels). Clustering technology, known as Beowulf, enables Linux users to create systems of dozens or hundreds of inexpensive, commodity personal computers that, combined, crank out supercomputer level process- ing speed very inexpensively compared to the cost of, say, a Cray, an SGI, or a Sun.
0372316072 CH01 7/26/99 2:01 PM Page 9 Overview 9 CHAPTER 1 On the desktop, too, Linux continues to mature. The KDE desktop provides a GUI that 1 rivals Microsoft Windows for ease of use and configurability. Unlike Windows, however, KDE is a thin layer of eye candy on top of the operating system. The powerful com- OVERVIEW mand-line interface is never more than one click away. Indeed, as this book went to press, Caldera Systems released version 2.2 of OpenLinux, which contained a graphical, Windows-based installation procedure! No less than four office productivity suites exist or will soon be released: Applixware, Star Office, and Koffice, part of the KDE project, are in active use. Corel is finishing up work on their office suite, although WordPerfect 8 for Linux is already available. On top of the huge array of applications and utilities avail- able for Linux, the emergence of office applications every bit as complete as Microsoft Office establishes Linux as a viable competitor to Windows on the desktop. A Brief History of Linux Linux began with this post to the Usenet newsgroup comp.os.minix, in August, 1991, written by a Finnish college student: Hello everybody out there using minix- I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones. That student, of course, was Linus Torvalds and the “hobby” of which he wrote grew to what is known today as Linux. Version 1.0 of the kernel was released on March 14, 1994. Version 2.2, the current stable kernel release, was officially released on January 25, 1999. Torvalds wrote Linux because he wanted a UNIX-like operating system that would run on his 386. Working from MINIX, Linux was born. Linux and UNIX Officially and strictly speaking, Linux is not UNIX. UNIX is a registered trademark, and using the term involves meeting a long list of requirements and paying a sizable amount of money to be certified. Linux is a UNIX clone, a work-alike. All of the kernel code was written from scratch by Linus Torvalds and other kernel hackers. Many programs that run under Linux were also written from scratch, but many, many more are simply ports of software from other operating systems, especially UNIX and UNIX-like operat- ing systems. More than anything else, Linux is a POSIX operating system. POSIX is a family of stan- dards developed by the Institute of Electrical and Electronic Engineers (IEEE) that define a portable operating system interface. Indeed, what makes Linux such a high quality UNIX clone is Linux’s adherence to POSIX standards.
0372316072 CH01 7/26/99 2:01 PM Page 10 The Linux Programming Toolkit 10 PART I Programming Linux As Linux continues to mature, the need for people who can program for it will grow. Whether you are a just learning to program or are an experienced programmer new to Linux, the array of tools and techniques can be overwhelming. Just deciding where to begin can be difficult. This book is designed for you. It introduces you to the tools and techniques commonly used in Linux programming. We sincerely hope that what this book contains gives you a solid foundation in the practical matters of programming. By the time you finish this book, you should be thoroughly prepared to hack Linux. Why Linux Programming? Why do people program on and for Linux? The number of answers to that question is probably as high as the number of people programming on and for Linux. I think, though, that these answers fall into several general categories. First, it is fun—this is why I do it. Second, it is free (think beer and speech). Third, it is open. There are no hidden interfaces, no undocumented functions or APIs (application programming interfaces), and if you do not like the way something works, you have access to the source code to fix it. Finally, and I consider this the most important reason, Linux programmers are part of a special community. At one level, everyone needs to belong to something, to identify with something. This is as true of Windows programmers as it is of Linux programmers, or people who join churches, clubs, and athletic teams. At another, more fundamental level, the barriers to entry in this community are based on ability, skill, and talent, not money, looks, or who you know. Linus Torvalds, for example, is rarely persuaded to change the kernel based on rational arguments. Rather, working code persuades him (he often says “Show me the code.”). I am not supposing or proposing that Linux is a meritocracy. Rather, one’s standing in the community is based on meeting a communal need, whether it is hacking code, writ- ing documentation, or helping newcomers. It just so happens, though, that doing any of these things requires skill and ability, as well as the desire to do them. As you participate in and become a member of Linux’s programming community, we hope, too, that you will discover that it is fun and meaningful as well. I think it is. In the final analysis, Linux is about community and sharing as much as it is about making computers do what you want.
0372316072 CH01 7/26/99 2:01 PM Page 11 Overview 11 CHAPTER 1 Summary 1 This chapter briefly recounted Linux’s history, took a whirlwind tour of the state of OVERVIEW Linux and Linux programming today, and made some reasonable predictions about the future of Linux. In addition, it examined Linux’s relationship to UNIX and took a brief, philosophical look at why you might find Linux programming appealing.
0472316072 CH02 7/26/99 2:00 PM Page 13 Setting Up a Development System CHAPTER 2 by Mark Whitis IN THIS CHAPTER • Hardware Selection 14 • Processor/Motherboard 15 • User Interaction Hardware: Video, Sound, Keyboard, and Mouse 19 • Keyboard and Mouse 23 • Communication Devices, Ports, and Buses 24 • Storage Devices 29 • External Peripherals 30 • Complete Systems 33 • Laptops 34 • Installation 34
0472316072 CH02 7/26/99 2:00 PM Page 14 The Linux Programming Toolkit 14 PART I Hardware Selection This section is, of necessity, somewhat subjective. Choice of a system depends largely on the developer’s individual needs and preferences. This section should be used in conjunc- tion with the Hardware Compatibility HOWTO, as well as the more specialized HOWTO documents. The latest version is online at http://metalab.unc.edu/LDP/HOWTO/ Hardware-HOWTO.html; if you do not have Net access, you will find a copy on the accompanying CD-ROM or in /usr/doc/HOWTO on most Linux systems (if you have one available). The Hardware HOWTO often lists specific devices that are, or are not, sup- ported, or refers you to documents that do list them. This section will not try to list spe- cific supported devices (the list would be way too long and would go out of date very rapidly) except where I want to share specific observations about a certain device based on my own research or experience. Internet access is strongly recommended as a prerequisite to buying and installing a Linux system. The latest versions of the HOWTO documents can be found on the Net at Linux Online (http://www.linux.org/) in the Support section. The Projects section has many useful links to major development projects, including projects to support various classes of hardware devices. If you do not have Net access, the HOWTO documents are on the accompanying Red Hat Linux CDs (Disc 1 of 2) in the /doc/HOWTO directory. Considerations for Selecting Hardware I will try to give you an idea of what is really needed and how to get a good bang for your buck rather than how to get the most supercharged system available. You may have economic constraints or you may prefer to have two or more inexpensive systems instead of one expensive unit. There are many reasons for having two systems, some of which include the following: • To have a separate router/firewall • To have a separate “crash and burn” system • To have a system that boots one or more other operating systems • To have a separate, clean system to test installation programs or packages (RPM or Debian) if you are preparing a package for distribution • To have a separate untrusted system for guests if you are doing sensitive work • To have at least one Linux box to act as a server that runs Linux 24 hours a day Most of the millions of lines of Linux code were probably largely developed on systems that are slower than the economy systems being sold today. Excessive CPU power can be detrimental on a development station because it may exacerbate the tendency of some
0472316072 CH02 7/26/99 2:00 PM Page 15 Setting Up a Development System 15 CHAPTER 2 developers to write inefficient code. If, however, you have the need and economic resources to purchase a system more powerful than I suggest here, more power to you (please pardon the pun). A good developer’s time is very valuable, and the extra power can pay for itself if it saves even a small percentage of your time. The suggestions in this chapter will be oriented toward a low- to mid-range development workstation. You can adjust them upward or downward as appropriate. I do not want you to be discouraged from supporting the Linux platform, in addition to any others you may currently support, by economic considerations. Basic development activities, using the tools described in this book, are not likely to 2 demand really fast CPUs; however, other applications the developer may be using, or DEVELOPMENT SETTING UP A even developing, may put additional demands on the CPU and memory. Editing and SYSTEM compiling C programs does not require much computing horsepower, particularly since make normally limits the amount of code that has to be recompiled at any given time. Compiling C++ programs, particularly huge ones, can consume large amounts of com- puting horsepower. Multimedia applications demand more computing power than edit and compile cycles. The commercial Office suites also tend to require large amounts of memory. If you like to use tracepoints to monitor variables by continuous single step- ping, that could heavily consume CPU cycles. Some people will recommend that you choose a system that will meet your needs for the next two or three years. This may not be a wise idea. The cost of the computing power and features you will need a year from now will probably drop to the point where it may be more cost effective for you to buy what you need today, and wait until next year to buy what you need then. If you do not replace your system outright, you may want to upgrade it piecemeal as time passes; if that is the case, you don’t want to buy a system with proprietary components. Processor/Motherboard One of the most important features of a motherboard is its physical form factor, or its size and shape and the locations of key features. Many manufacturers, particularly major brands, use proprietary form factors, which should be avoided. If you buy a machine that has a proprietary motherboard and you need to replace it due to a repair or upgrade, you will find your selection limited (or non-existent) and overpriced. Some manufacturers undoubtedly use these proprietary designs to lower their manufacturing cost by eliminat- ing cables for serial, parallel, and other I/O ports; others may have more sinister motives. The older AT (or baby AT) form factor motherboards are interchangeable, but have very little printed circuit board real estate along the back edge of the machine on which to
0472316072 CH02 7/26/99 2:00 PM Page 16 The Linux Programming Toolkit 16 PART I mount connectors. The case only has holes to accommodate the keyboard and maybe a mouse connector. The newer ATX standard has many advantages. Although an ATX motherboard is approximately the same size and shape as a baby AT motherboard (both are about the same size as a sheet of 8-1/2”×11” writing paper), the ATX design rotates the dimensions so the long edge is against the back of the machine. An ATX case has a standard rectangular cutout that accommodates metal inserts, which have cutouts that match the connectors on a particular motherboard. The large cutout is large enough to easily accommodate the following using stacked connectors: • 2 serial ports • 1 parallel port • keyboard port • mouse port • 2 USB ports • VGA connector • audio connectors Also, ATX moves the CPU and memory where they will not interfere with full-length I/O cards, although some manufacturers still mount some internal connectors where they will interfere. Many case manufacturers have retooled. More information about the ATX form factor can be found at http://www.teleport.com/~atx/. Figure 2.1 illustrates the phys- ical difference between AT and ATX form factors. FIGURE 2.1 IO AT versus ATX CPU motherboard form factors. Memory AT ATX Onboard I/O A typical Pentium or higher motherboard will have two serial, one parallel, one key- board, one mouse, IDE, and floppy ports onboard; all of which are likely to work fine with Linux. It may have additional ports onboard that will have to be evaluated for com- patibility, including USB, SCSI, Ethernet, Audio, or Video.
0472316072 CH02 7/26/99 2:00 PM Page 17 Setting Up a Development System 17 CHAPTER 2 Processor For the purposes of this section, I will assume you are using an Intel or compatible processor. The use of such commodity hardware is likely to result in a lower-cost system with a wider range of software available. There are a number of other options available, including Alpha and Sparc architectures. Visit http://www.linux.org/ if you are inter- ested in support for other processor architectures. Cyrix and AMD make Pentium compatible processors. There have been some compatibi- lity problems with Cyrix and AMD processors, but these have been resolved. I favor Socket 7 motherboards, which allow you use Intel, Cyrix, and AMD processors inter- 2 changeably. There are also some other companies that make Pentium compatible DEVELOPMENT SETTING UP A processors that will probably work with Linux but have been less thoroughly tested. IDT SYSTEM markets the Centaur C6, a Pentium compatible processor, under the unfortunate name “Winchip,” which apparently will run Linux, but I don’t see the Linux community lining up to buy these chips. IBM used to make and sell the Cyrix chips under its own name in exchange for the use of IBM’s fabrication plant; these may be regarded simply as Cyrix chips for compatibility purposes. Future IBM x86 processors will apparently be based on a different core. The Pentium II, Pentium III, Xeon, and Celeron chips will simply be regarded as Pentium compatible CPUs. There have been some very inexpensive systems made recently that use the Cyrix MediaGX processor. These systems integrate the CPU, cache, Video, Audio, motherboard chipset, and I/O onto two chips. The downside is that you cannot replace the MediaGX with another brand of processor and that the video system uses system memory for video. This practice slightly reduces the available system memory and uses processor/memory bandwidth for screen refresh, which results in a system that is about a third slower than you would expect based on the processor speed. The advantages are the lower cost and the fact that all Media GX systems are basically the same from a software point of view. Therefore, if you can get one Media GX system to work, all others should work. Video support for the Media GX is provided by SuSE (go to http://www.suse.de/XSuSE/ XSuSE_E.html for more info) and there is a MediaGX video driver in the KGI. Audio support has not been developed at the time of this writing, although it may be available by the time this book is published. My primary development machines have been running Linux for a couple years on Cyrix P150+ processors (equivalent to a 150MHz Pentium) and upgrading the processor is still among the least of my priorities. Given current processor prices, you will probably want to shoot for about twice that speed, adjusting up or down based on your budget and avail- ability.
0472316072 CH02 7/26/99 2:00 PM Page 18 The Linux Programming Toolkit 18 PART I The Linux community seems to be waiting with interest to see the processor being devel- oped by Transmeta, the company that hired Linus Torvalds and some other Linux gurus (including my friend, Jeff Uphoff). The speculation, which is at least partially corroborat- ed by the text of a patent issued to the company, is that this processor will have an archi- tecture that is optimized for emulating other processors by using software translators and a hardware translation cache. It is suspected that this chip may be a very good platform for running Linux. Linux might even be the native OS supported on this chip under which other operating systems and processor architectures are emulated. BIOS For a basic workstation, any of the major BIOS brands (AWARD, AMIBIOS, or Phoenix) may suffice. The AMI BIOS has some problems that complicate the use of I/O cards that have a PCI-to-PCI bridge such as the Adaptec Quartet 4 port ethernet cards. The AWARD BIOS gives the user more control than does AMIBIOS or Phoenix. A flash BIOS, which allows the user to download BIOS upgrades, is desirable and is standard on most modern systems. Older 386 and 486 systems tend not to have a flash BIOS and may also have the following problems: • An older BIOS that may not be Y2K compliant • May not support larger disk drives • May not support booting off of removable media Memory 64MB is reasonable for a typical development system. If you are not trying to run X win- dows, you may be able to get by with only 8MB for a special purpose machine (such as a crash and burn system for debugging device drivers). Kernel compile times are about the same (less than1.5 minutes) with 32MB or 64MB (although they can be much longer on a system with 8MB). If you want to run multimedia applications (such as a Web browser), particularly at the same time you are compiling, expect the performance to suf- fer a bit if you only have 32MB. Likewise, if you are developing applications that con- sume lots of memory, you may need more RAM. This page was written on a system with 32MB of RAM but one of the other authors’ primary development system has ten times that amount of memory to support Artificial Intelligence work. Enclosure and Power Supply Select an enclosure that matches your motherboard form factor and has sufficient drive bays and wattage to accommodate your needs. Many case manufacturers have retooled
0472316072 CH02 7/26/99 2:00 PM Page 19 Setting Up a Development System 19 CHAPTER 2 their AT form factor cases to accommodate the ATX motherboard; if you order an AT case, you may receive a newer ATX design with an I/O shield that has cutouts for AT keyboard and mouse ports. For most applications, Mini-Tower, Mid-Tower, or Full- Tower cases are likely to be the preferred choices. For some applications you may want server or rack mount designs. NOTE The power supply connectors are different for AT and ATX power supplies. 2 DEVELOPMENT SETTING UP A If you are building a mission-critical system, be aware that some power supplies will not SYSTEM restore power to the system after a power outage. You may also be interested in a mini- redundant power supply; these are slightly larger than a normal ATX or PS/2 power sup- ply but some high end cases, particularly rack mount and server cases, are designed to accommodate either a mini-redundant or a regular ATX or PS/2 supply. User Interaction Hardware: Video, Sound, Keyboard, and Mouse The devices described in this section are the primary means of interacting with the user. Support for video cards and monitors is largely a function of adequate information being available from the manufacturer or other sources. Monitors usually require only a hand- ful of specifications to be entered in response to the Xconfigurator program, but support for a video card often requires detailed programming information and for someone to write a new driver or modify an existing one. Sound cards require documentation and programming support, like video cards, but speakers need only be suitable for use with the sound card itself. Video Card If you only need a text mode console, most VGA video adapters will work fine. If you need graphics support, you will need a VGA adapter that is supported by Xfree86, SVGAlib, vesafb, and/or KGI. Xfree86 is a free open-source implementation of the X Windowing System, which is an open-standard-based windowing system that provides display access to graphical appli- cations running on the same machine or over a network. Xfree86 support is generally
0472316072 CH02 7/26/99 2:00 PM Page 20 The Linux Programming Toolkit 20 PART I necessary and sufficient for a development workstation. For more information, visit http://www.xfree86.org/. For drivers for certain new devices, check out XFcom (formerly XSuSE) at http://www.suse.de/XSuSE/. SVGAlib is a library for displaying full screen graphics on the console. It is primarily used for a few games and image viewing applications, most of which have X Windowing System versions or equivalents. Unfortunately, SVGAlib applications need root privi- leges to access the video hardware so they are normally installed suid, which creates security problems. GGI, which stands for Generic Graphics Interface, tries to solve the problems of needing root access, resolve conflicts between concurrent SVGAlib and X servers, and provide a common API for writing applications to run under both X and SVGAlib. A part of GGI, called KGI, provides low-level access to the framebuffer. GGI has also been ported to a variety of other platforms so it provides a way of writing portable graphics applications, although these applications are apparently limited to a single window paradigm. Documentation is very sparse. This package shows future promise as the common low- level interface for X servers and SVGAlib and a programming interface for real-time action games. OpenGL (and its predecessor GL) has long been the de facto standard for 3D modeling. OpenGL provides an open API but not an open reference implementation. Mesa provides an open source (GPL) implementation of an API very similar to OpenGL that runs under Linux and many other platforms. Hardware acceleration is available for 3Dfx Voodoo–based cards. For more information on Mesa, visit http://www.mesa3d.org/. Metrolink provides a licensed OpenGL implementation as a commercial product; visit http://www.metrolink.com/opengl/ for more information. Frame buffer devices pro- vide an abstraction for access to the video buffer across different processor architectures. The Framebuffer HOWTO, at http://www.tahallah.demon.co.uk/programming/ HOWTO-framebuffer-1.0pre3.html, provides more information. Vesafb provides frame buffer device support for VESA 2.0 video cards on Intel platforms. Unfortunately, the VESA specification appears to be a broken specification that only works when the CPU is in real mode instead of protected mode, so switching video modes requires switching the CPU out of protected mode to run the real mode VESA VGA BIOS code. Such shenanigans may be common in the MS Windows world and may contribute to the insta- bility for which that operating system is famous. KGIcon allows the use of KGI support- ed devices as framebuffer devices.
0472316072 CH02 7/26/99 2:00 PM Page 21 Setting Up a Development System 21 CHAPTER 2 *Tip Some companies offer commercial X servers for Linux and other UNIX- compatible operating systems. Among them are Accelerated-X (http://www.xigraphics.com/) and Metro-X (http://www.metrolink.com/). AGP (Accelerated Graphics Port) provides the processor with a connection to video memory that is about four times the speed of the PCI bus and provides the video acceler- ator with faster access to texture maps stored in system memory. Some AGP graphics 2 cards are supported under Linux. DEVELOPMENT SETTING UP A SYSTEM *Tip To determine which video cards and monitors are supported under Red Hat run /usr/X11/bin/Xconfigurator --help as root on an existing system. You will probably want at least 4MB of video memory to support 1280×1024 at 16bpp (2.6MB). You will need 8MB to support 1600×1200 at 32bpp. Some 3D games might benefit from extra memory for texture maps or other features if they are able to use the extra memory. The X server will use some extra memory for a font cache and to expand bitmap. If you want to configure a virtual screen that is larger than the physical screen (the physical screen can scroll around the virtual screen when you move the cursor to the edge) be sure to get enough memory to support the desired virtual screen size. The FVWM window manager will create a virtual desktop that is by default four times the virtual screen size, and will switch screens if you move the cursor to the edge of the screen and leave it there momentarily; instead of using extra video memory, this feature is implemented by redrawing the whole screen. The X server may use system memory (not video memory) for “backing store” to allow it to redraw partially hidden windows faster when they are revealed. If you use high resolution or pixel depth (16bpp or 32bpp) screens, be aware that backing store will place additional demands on system memory. There are some distinct advantages to installing a video card that supports large resolu- tion and pixel depth in your Linux system. If you intend to make good use of the X serv- er, this can be invaluable. Since Linux can easily handle many different processes at
0472316072 CH02 7/26/99 2:00 PM Page 22 The Linux Programming Toolkit 22 PART I once, you will want to have enough screen real estate to view multiple windows. A video card that can support 1280×1024 resolution will satisfy this nicely. The other advantage to a good video card is the pixel depth. Not only do the newer window managers run more smoothly with the better pixel depth, it is also very useful if you want to use your system for graphics work. Your monitor also has to be able to support the resolution of your video card—otherwise you could not take full advantage of the capabilities your system offers. (The following section discusses monitor selection in more detail.) It is very important that you check the specifications of your hardware when deciding which video card/monitor combination to use so that the two will work well together. Also, it is always important to check out the hardware compatibility lists for Linux. Monitor Almost any monitor that is compatible with your video card will work under Linux if you can obtain the specifications, particularly the vertical and horizontal refresh rates or ranges supported and the video bandwidth. Note that bigger is not always better. What matters is how many pixels you can put on the screen without sacrificing quality. I prefer the 17” monitor I have on my development machine at one office to the very expensive 20” workstation monitor that sits next to it. I prefer many 15” monitors to their 17” counterparts. If you have trouble focusing up close or want to sit very far away from your monitor, you may need a large monitor, but otherwise a quality smaller monitor closer to your head may give you equal or better quality at a lower price. As discussed in the preceding section, the monitor and video card selections are very closely related. It is good to test your monitor selection for clarity. One of the main con- tributing factors to the clarity of a monitor is the dot pitch—the smaller the spacing between pixels, the better. However, this can boost the price of a monitor. The other issue here, again, is related to the video card. One monitor tested with different video cards can have quite different results. A video card aimed more for business use (such as a Matrox Millenium G200) will often produce a crisper image than a video card that is intended for game use (such as Diamond V550). This is because some cards are opti- mized for good 2D, 3D, or crisp text, but are not optimized for all three. I recommend running your monitor at as close to 60Hz as you can even if it can run at 70Hz or higher. In some cases a monitor may look better at 70Hz, particularly if you are hyped up on massive doses of caffeine and your monitor has short persistence phosphors, but I find that usually it looks better at 60Hz. The reason for this is the ubiquitous 60Hz interference from power lines, transformers, and other sources. Not only can this interfer- ence be picked up in the cables and video circuitry but it also affects the electron beams in the monitor’s cathode ray tube (CRT) directly. Shielding is possible but expensive and
0472316072 CH02 7/26/99 2:00 PM Page 23 Setting Up a Development System 23 CHAPTER 2 is not likely to be found in computer video monitors. If your image is visibly waving back and forth, this is likely to be your problem. If the beat frequency (the difference between the two frequencies) between the 60hz interference and the refresh rate is close to zero, the effect will slow and become imperceptible. But if the beat frequency is larger you will have instabilities that will be either very perceptible or more subtle but irritat- ing. So a beat frequency of 0.1Hz (60Hz versus 60.1Hz) is likely to be fine but a beat frequency of 10Hz (60Hz versus 70Hz) is likely to be very annoying. Some countries use a frequency other than 60Hz for their power grid; in those countries, you would need to match the refresh rate to the local power line frequency to avoid beat 2 frequency problems. Incidentally, some monitors deliberately make the image wander DEVELOPMENT SETTING UP A around the screen slightly at a very slow rate to prevent burn-in; as long as this is very SYSTEM slow, it is imperceptible (your own head movements are likely to be far greater). The video configuration in Linux gives you much latitude in how you want to set up your hardware. It is important to remember to have your settings within the specified ranges for your hardware. Pushing the limits can result in poor performance or even the destruction of your hardware. Sound Cards Linux supports a variety of sound cards, particularly Sound Blaster compatible (but not all sound cards that claim to be compatible are—some use software assisted emulation), older ESS chip-based cards (688 and 1688), Microsoft Sound System– based cards, and many Crystal (Cirrus Logic) based cards. Consult the Hardware Compatibility HOWTO document, Four Front Technologies Web site (at http://www.4front-tech.com/), or the Linux kernel sources (browsable on the Net at http://metalab.unc.edu/ linux-source/) for more information. Four Front Technologies sells a package that includes sound drivers for many cards that are not supported by the drivers shipped with the kernel. Most newer sound cards seem to be PnP devices. Support for PnP cards is available using the ISAPnP utilities mentioned above or the Four Front drivers. Keyboard and Mouse USB keyboards and mice are not recommended at this time; see “USB and Firewire (IEEE 1394),” later in this chapter for more details. Normal keyboards that connect to a standard AT or PS/2 style keyboard port should work fine, although the unusual extra features on some keyboards may not work. Trackball, Glidepoint, and Trackpad pointing devices that are built in to the keyboard normally have a separate connection to a serial or PS/2 mouse port and may be regarded as separate mouse devices when considering
0472316072 CH02 7/26/99 2:00 PM Page 24 The Linux Programming Toolkit 24 PART I software support issues. Normal PS/2 and serial mice are supported, including those that speak Microsoft, Mouse Systems, or Logitech protocols. Mouse support is provided by the gpm program and/or the X server. Many other pointing devices, including trackballs, Glidepoints, and Trackpads will work if they emulate a normal mouse by speaking the same communications protocol; some special features of newer trackpads, such as pen input and special handling of boarder areas, may not work. Many X applications require a three-button mouse, but gpm and the X server can be configured to emulate the extra middle button by chording both buttons on a two-button mouse. Communication Devices, Ports, and Buses This section contains information on various devices that provide communications chan- nels. These channels can be used to communicate with other computers and with internal or external peripherals. The high-speed buses that connect expansion cards to the processor are included here. Neither the ISA bus nor the PCI bus will be covered in detail, although ISA Plug and Play devices and PCMCIA cards will have their own subsection since there are some special considerations. Plain ISA and PCI cards should work fine as long as there is a driver that supports that specific card. Most IDE controllers will work; for other IDE devices, see “Storage Devices,” later in this chapter. Devices that connect to a parallel (printer) port are discussed in their separate categories. Modems Most modems, with the exception of brain-dead winmodem types, modems that use the proprietary Rockwell Protocol Interface (RPI), or modems that depend on a software component for their functionality will work fine with Linux. Be aware, however, that there is a real difference between the more expensive professional models and the cheap- er consumer grade models. Almost any modem will perform well on good quality phone lines, but on poor quality lines the distinction will become significant. That is why you will see people on the Net who are both pleased and extremely dissatisfied with the same inexpensive modems. It requires much more sophisticated firmware and several times as much processing power to resurrect data from a poor quality connection as it does to recover data from a good connection. Serious developers are likely to want a dedicated Internet connection to their small office or to their home. Some more expensive modems can operate in leased line mode. This allows you to create a dedicated (permanent) 33.6Kbps leased line Internet connection
0472316072 CH02 7/26/99 2:00 PM Page 25 Setting Up a Development System 25 CHAPTER 2 over a unconditioned 2 wire (1 pair) dry loop. This can be handy if ISDN and xDSL are not available in your area. A dry loop is a leased telephone line with no line voltage, ringing signal, or dial tone that permanently connects two locations. It is sometimes referred to as a “burglar alarm pair.” These lines are very inexpensive for short distances. The average person working in a telco business office has no clue what these terms mean. Expect to pay $200 or more for a modem that supports this feature. Your chances of finding a pair of leased line modems that will work at 56K are not very good since only modems with a digital phone line interface are likely to have the soft- ware to handle 56K answer mode. I used a pair of leased line capable modems for a cou- 2 ple years over a wire distance of two or three miles, at a cost of about $15 per month; DEVELOPMENT SETTING UP A more information on how to set this up is available on my Web site (http:// SYSTEM www.freelabs.com/~whitis/unleashed/). It is also possible to run xDSL over a rela- tively short distance dry loop (I now use MVL, a variant of DSL which works better on longer lines and provides 768Kbps, on the same dry loop) even though xDSL is intended to be used with one of the modems located in the central office; this costs about $13,000 for 16 lines and the equipment is not, as far as I know, readily available in configurations that are economically viable for a small number of lines. If you can spread the capital cost over many lines, xDSL can be very economical compared to ISDN or T1 lines. In my example, a dry loop costs $15 per month and provides a 768K connection versus $75 per month for an ISDN line or $400 per month for a T1 line (these charges are for local loop only and do not include IP access). If you want to support incoming (dial-in or answer mode) 56K connections, you will need a modem with a digital phone line interface. Normally, ISPs use expensive modem racks that have a T1 line interface for this purpose, which is only economically viable if you are supporting dozens of lines. You might be able to find a modem that functions both as an ordinary modem and as an ISDN terminal adapter and can produce 56K answer mode modulation over an ISDN line. If you want to set up a voice mail or interactive voice response (IVR) system, you will probably want a modem that is capable of voice operation and is compatible with the vgetty software. Check the Mgetty+Sendfax with Vgetty Extensions (FAQ) document for voice modem recommendations. For fax operation, your software choices include HylaFAX, mgetty+sendfax, and efax. A modem that supports Class 2.0 FAX operation is preferred over one that can only do Class 1 fax. Class 1 modems require the host computer to handle part of the real time fax protocol processing and will malfunction if your host is too busy to respond quickly. Class 2.0 modems do their own dirty work. Class 2 modems conform to an earlier version of the Class 2.0 specification, which was never actually released as a standard.
0472316072 CH02 7/26/99 2:00 PM Page 26 The Linux Programming Toolkit 26 PART I The mgetty+sendfax and efax packages come with Red Hat 5.2. HylaFAX comes on the Red Hat Powertools CD. All three packages can be downloaded off the Internet. HylaFAX is more complicated to set up but is better for an enterprise fax server since it is server based and there are clients available for Linux, Microsoft Windows, MacOS, and other platforms. Table 2.1 summarizes fax capabilities. TABLE 2.1 FAX SUPPORT Class 1 Class 2 Class 2.0 HylaFax Yes Yes Yes Sendfax No Yes Yes Efax Yes Yes Support untested Network Interface Cards The Tulip chips are considered by many to be the best choice for a PCI-based ethernet card on a Linux system. They are fairly inexpensive, fast, reliable, and documented. There have been some problems lately, however. There have been frequent, often slightly incompatible, revisions to newer chips. The older chips, which were a safer choice, were discontinued (this is being reversed) and the line was sold to competitor Intel, and there was a shortage of cards. Many of these problems may be corrected by the time this book is released, however; check the Tulip mailing list archives for more details. If you need multiple ethernet interfaces in a single machine, Adaptec Quartet cards provide four Tulip-based ethernet ports on a single machine. One of my Web pages gives more infor- mation on using the Quartets under Linux. For an inexpensive ISA 10MB/s card, the cheap NE2000 clones usually work well. These cards tie up the CPU a bit more than more sophisticated designs when transferring data, but are capable of operating at full wire speed. (Don’t expect full wire speed on a single TCP connection such as an FTP transfer, however—you will need several simulta- neous connections to get that bandwidth.) 3Com supports their ethernet boards under Linux, and Crystal (Cirrus Logic) offers Linux drivers for their ethernet controller chips. Most WAN card manufacturers also seem to provide Linux Drivers. SDL, Emerging Technologies, and Sangoma provide Linux drivers.
0472316072 CH02 7/26/99 2:00 PM Page 27 Setting Up a Development System 27 CHAPTER 2 SCSI Linux supports most SCSI controllers, including many RAID controllers, host adapters, almost all SCSI disks, most SCSI tape drives, and many SCSI scanners. Some parallel port–based host adapters are notable exceptions. Advansys supports their SCSI adapters under Linux; the drivers that ship with the kernel were provided by Advansys. The Iomega Jaz Jet PCI SCSI controller, which may be available at local retailers, is actually an Advansys controller and is a good value. It is a good idea not to mix disk drives and slow devices such as tape drives or scanners on the same SCSI bus unless the controller (and its driver) and all of the slow devices on the bus support a feature known as “dis- 2 connect-reconnect”; it is rather annoying to have your entire system hang up for 30 sec- DEVELOPMENT SETTING UP A onds or more while the tape rewinds or the scanner carriage returns. The SCSI HOWTO SYSTEM has more information on disconnect-reconnect. *Warning Beware of cheap SCSI controllers, particularly those that do not use interrupts. In my limited experience with boards of this type, they often did not work at all or would cause the system to hang for several seconds at a time. This may be due to bugs in the driver for the generic NCR5380/NCR53c400 driver although in at least on case the card was defective. The SCSI controllers I had trouble with came bundled with scanners or were built-in on certain sound boards. USB and Firewire (IEEE 1394) USB and Firewire support are being developed. USB support is provided by a package called UUSBD. It is apparently possible to use a USB mouse if you have a supported USB controller (although you will need to download and install the code before you can run X) but keyboards don’t work at the time of this writing. It is probably too early to plan on using either of these on a development system except for tinkering. Links to these projects are on linux.org under projects. Serial Cards (Including Multiport) Standard PC serial ports are supported, on or off the motherboard. Very old designs that do not have a 16550A or compatible UART are not recommended but those are likely to be pretty scarce these days.
0472316072 CH02 7/26/99 2:00 PM Page 28 The Linux Programming Toolkit 28 PART I Most intelligent multiport serial cards are supported, often with direct support from the manufacturer. Cyclades, Equinox, Digi, and GTEK are some of the companies that sup- port their multiport boards under Linux. Equinox also makes an interesting variation on a serial port multiplexor that supports 16 ISA Modems (or cards that look exactly like modems to the computer) in an external chassis. Most dumb multiport serial cards also work, but beware of trying to put too many dumb ports in a system unless the system and/or the ports are lightly loaded. Byterunner (http://www.byterunner.com) supports their inexpensive 2/4/8 port cards under Linux; unlike many dumb multiport boards, these are highly configurable, can optionally share interrupts, and support all the usual handshaking signals. IRDA Linux support for IRDA (Infrared Data Association) devices is fairly new, so be prepared for some rough edges. The Linux 2.2 Kernel is supposed to have included IRDA support, but you will still need the irda-utils even after you upgrade to 2.2. The IRDA project’s home page is at http://www.cs.uit.no/linux-irda/. I suspect that most laptops that support 115Kbps SIR IRDA may emulate a serial port and won’t be too hard to get working. PCMCIA Cards Linux PCMCIA support has been around for a while and is pretty stable. A driver will need to exist for the particular device being used. If a device you need to use is not listed in the /etc/pcmcia/config file supplied on the install disks for your Linux distribution, installation could be difficult. ISA Plug and Play Although some kernel patches exist for Plug and Play, support for PnP under Linux is usually provided using the ISAPnP utilities. These utilities do not operate automatically, as you might expect for plug and play support. The good news is that this eliminates the unpredictable, varying behavior of what is often referred to more accurately as “Plug and Pray.” You run one utility, pnpdump, to create a sample configuration file with the various configurations possible for each piece of PnP hardware, and then you manually edit that file to select a particular configuration. Red Hat also ships a utility called sndconfig, which is used to interactively configure some PnP sound cards. Avoid PnP for devices that are needed to boot the system, such as disk controllers and network cards (for machines that boot off the network).
0472316072 CH02 7/26/99 2:00 PM Page 29 Setting Up a Development System 29 CHAPTER 2 Storage Devices Linux supports various storage devices commonly used throughout the consumer com- puter market. These include most hard disk drives and removable media such as Zip, CD-ROM/DVD, and tape drives. Hard Disk Virtually all IDE and SCSI disk drives are supported under Linux. Linux even supports some older ST506 and ESDI controllers. PCMCIA drives are supported. Many software 2 and hardware RAID (Reliable Array of Independent Disks) configurations are supported DEVELOPMENT SETTING UP A to provide speed, fault tolerance, and/or very large amounts of disk storage. A full Red SYSTEM Hat 5.2 with Powertools and Gnome sampler installation and all source RPMs installed, but not unpacked, will take about 2.5GB of disk space. Removable Disks More recent versions of the Linux kernel support removable media including Jaz, LS120, Zip, and other drives. Using these drives as boot devices can be somewhat problematic. My attempts to use a Jaz disk as a boot device were thwarted by the fact that the drive apparently destroyed the boot disk about once a month; this may have just been a defec- tive drive. Problems with the LS120 included being unable to use an LS120 disk as a swap device because of incompatible sector sizes. Also be warned that there are software problems in writing a boot disk on removable media on one computer and using it to boot another living at a separate device address (for example, an LS120 might be the third IDE device on your development system but the first on the system to be booted). CD-ROM/DVD Almost all CD-ROM drives will work for data, including IDE, SCSI, and even many older proprietary interface drives. Some parallel port drives also work, particularly the Microsolutions Backpack drives (which can be used to install more recent versions of Red Hat). Some drives will have trouble being used as an audio CD player due to a lack of standardization of those functions; even fewer will be able to retrieve “red book” audio (reading the digital audio data directly off of an audio CD into the computer for duplication, processing, or transmission). Linux has support for many CD changers. The eject command has an option to select individual disks from a changer. I found that this worked fine on a NEC 4x4 changer. Recording of CD-R and CD-RW disks is done using the cdrecord program. The UNIX
0472316072 CH02 7/26/99 2:00 PM Page 30 The Linux Programming Toolkit 30 PART I CD-Writer compatibility list at http://www.guug.de:8080/cgi-bin/winni/lsc.pl gives more information on which devices are compatible. Be warned that due to limita- tions of the CD-R drives, writing CDs is best done on very lightly loaded or dedicated machines; even a brief interruption in the data stream will destroy data, and deleting a very large file will cause even fast machines to hiccup momentarily. There are GUI front ends for burning CD’s available, including BurnIT and X-CD-Roast. Tape Backup A wide variety of tape backup devices are supported under Linux, as well as various other types of removable media. Linux has drivers for SCSI, ATAPI (IDE), QIC, floppy, and some parallel port interfaces. I prefer to use SCSI DAT (Digital Audio Tape) drives exclusively even though they can cost as much as a cheap PC. I have used Conner Autochanger DAT drives, and although I could not randomly select a tape in the changer under Linux, each time I ejected a tape the next tape would automatically be loaded. Other autochangers might perform differently. *Warning I caution against the use of compression on any tape device; read errors are common and a single error will cause the entire remaining portion of the tape to be unreadable. External Peripherals The devices in this section are optional peripherals that are normally installed outside the system unit. From a software perspective, the drivers for these devices usually run in user space instead of kernel space. Printer Printer support under Linux is primarily provided by the Ghostscript package (http://www.ghostscript.com/). Support for Canon printers is poor, probably due to Canon’s failure to make technical documentation available. Canon has refused to make documentation available for the BJC-5000 and BJC-7000 lines (which are their only inkjet printers that support resolutions suitable for good quality photographic printing). Most HP printers (and printers that emulate HP printers) are supported, due to HP
0472316072 CH02 7/26/99 2:00 PM Page 31 Setting Up a Development System 31 CHAPTER 2 making documentation available, except for their PPA-based inkjet printers, for which they will not release the documentation. The Canon BJC-5000, Canon BJC-7000, and HP PPA based printers are all partially brain dead printers that apparently do not have any onboard fonts and rely on the host computer to do all rasterization. This would not be a problem for Linux systems (except for the unusual case of a real time system log printer) since Ghostscript is normally used as a rasterizer and the onboard fonts and other features are not used. Some printers may be truly brain dead and not have any onboard CPU; these might use the parallel port in a very nonstandard manner to implement low level control over the printer hardware. The 2 HP720, HP820Cse, and HP1000 are PPA based printers. Partial support, in the form of a DEVELOPMENT SETTING UP A ppmtopba conversion utility, is available for some PPA printers based on reverse engi- SYSTEM neering. Some Lexmark inkjet printers might be supported, but many others are Windows-only printers. I have used a Lexmark Optra R+ laser printer with an Ethernet interface with Linux. It supports the LPD protocol so it is simply set up as a remote LPD device. A Linux box can act as a print server for Windows clients or act as a client for a Windows printer by using the Samba package. A Linux box can act as a print server for MacOS clients by using the Netatalk package. A Linux box running the ncpfs package can apparently serve as a print server for NetWare 2.x, 3.x, or 4.x clients with bindery access enabled, or print to a remote Netware printer. HP printers with JetDirect ethernet interfaces support LPD and will work as remote printers under Linux. Ghostscript can run on almost every operating system that runs on hardware with enough resources to function as a rasterizer. A single ghostscript driver (or PBM translator) is sufficient to support a printer on virtually every computer, including those running every UNIX-compatible operating system, MacOS, OS/2, and Windows 3.1, Windows 95, Windows 98, Windows NT, and many others. Ghostscript can coexist with, replace, or already is the native printing rasterizer (if any) on these operating systems and can inte- grate with the queuing system on almost all of these. Ghostscript can produce PBM (Portable BitMap) files. The use of a PBM translator can avoid various copyright issues since it does not have to be linked into a GPLed program. Therefore, the failure of print- er manufacturers to provide Ghostscript drivers or PBM translators is reprehensible. TIP More detailed information on printing under Linux can be found in the Linux Printing HOWTO.
0472316072 CH02 7/26/99 2:00 PM Page 32 The Linux Programming Toolkit 32 PART I Scanners Support for scanners is a bit sparse, although close to 100 different models from a couple dozen manufacturers are supported by the SANE package; manufacturers who not only fail to provide drivers themselves but also withhold documentation are culpable for this state of affairs. There have been various projects to support individual or multiple scanners under Linux. These have been eclipsed by the SANE package(http://www.mostang.com/sane/) which, no doubt, benefited from its predecessors. The name is a play on, and a potshot at, TWAIN, which passes for a standard in the Microsoft world. In TWAIN, the driver itself paints the dialog box that appears when you request a scan. This is not a “sane” way of doing things. It interferes with non-interactive scanning (such as from a command line, Web cgi, or production scanning applications), interferes with network sharing of a device, and interferes with making drivers that are portable across many platforms. SANE is able to do all of these things. In SANE, the driver has a list of attributes that can be controlled, and the application sets those attributes (painting a dialog box or parsing arguments as necessary). SANE has been ported to a variety of platforms including about 18 different flavors of UNIX and OS/2. SANE provides a level of abstraction for the low level SCSI interfaces, and abstractions are being worked on for a few other OS specific features (such as fork()) which interfere with portability to some platforms. SANE has not been ported to the Windows and MAC platforms, although there is no reason this can’t be done. Some have questioned the need to do this because the manufacturers ship drivers for these operating systems with most scanners. However, once SANE has been ported to these operating systems and a TWAIN to SANE shim has been written, there will be no legitimate reason for anyone to ever write another TWAIN driver again as long as the port and shim are distributed under license agreements that allow scanner manufacturers to distribute the software with their products. Digital Cameras There are programs to handle many hand-held digital cameras which will run Linux. Cameras that support compact flash or floppy disk storage of standard JPEG images should also work using those media to transfer the image data. A new application called gPhoto (http://gphoto.fix.no/gphoto/) supports about ten different brands of digital cameras. Some digital cameras may also be supported under the SANE library. There are software drivers for a variety of Frame Grabbers, TV tuners, and the popular Quickcam cameras available on the Net. Consult the relevant section of the Hardware Compatibility HOWTO for links to these resources.
0472316072 CH02 7/26/99 2:01 PM Page 33 Setting Up a Development System 33 CHAPTER 2 Home Automation I will give brief mention to a few gadgets that can be used to control the real world. There are a couple of programs to control the X10 CM11A (usually sold as part of the CK11A kit) computer interface module. The X10 system sends carrier current signals over your household or office power lines to control plug in, wall switch, or outlet mod- ules that switch individual devices on or off. The X10 carrier current protocol is patented but well documented; the documentation for the computer interface is available on the Net. The CM11A may be superseded by the CM14A by the time this gets into print. Nirvis systems makes a product called the Slink-e, which is an RS-232 device used to 2 control stereo and video gear using infrared, Control-S, S-link/Control-A1, and Control- DEVELOPMENT SETTING UP A A protocols. It can also receive signals from infrared remotes; this would allow you to SYSTEM write applications that record and replay remote control signals or respond to remote controls (handy for presentations). There is no Linux driver available yet, as far as I know, but the documentation is available from their Web site at http://www.nirvis.com/. Among other things, this unit can control a Sony 200 disk CD changer and not just queue up CD’s, but actually poll the track position and the disk seri- al number (other brands of CD players apparently cannot do this); the company supplies a Windows based CD player application that works with the Internet CD Database. The folks at Nirvus have already done the reverse engineering on some of the protocols. Complete Systems A number of companies specialize in preinstalled Linux systems. VA Research and Linux Hardware Solutions are two popular examples; consult the hardware section at Linux.org for a much more complete list of these vendors. Corel Computer Corp has versions of their Netwinder systems (which use StrongARM CPUs) with Linux preinstalled. These are fairly inexpensive systems aimed at the thin client and Web server market. Cobalt Networks offers the Qube, a Linux-based server appliance in a compact package that uses a MIPS processor. It appears that SGI will be supporting Linux on some of their MIPS based workstations. A few of the major PC brands have recently announced that they will be shipping some of their servers or workstations reconfigured with Linux, including Dell and Hewlett Packard. Compaq is now marketing a number of their systems to the Linux community, although apparently they are not available with Linux preinstalled. IBM has announced that they will be supporting Linux but it will apparently be up to the authorized reseller to preinstall it. Rumor has it that many other PC brands will announce preinstalled Linux systems by the time this book is printed.
0472316072 CH02 7/26/99 2:01 PM Page 34 The Linux Programming Toolkit 34 PART I Laptops Support for laptops is a bit tricky because laptops have short development cycles, often use very new semiconductors, and the manufacturers rarely provide technical documenta- tion. In spite of this, there is information on the Net concerning using Linux on approxi- mately 300 laptop models. Consult the Hardware Compatibility HOWTO document for links to pages that have the latest information on support for specific laptop models and features. *Note Linux supports a number of electronic pocket organizers. 3Com’s PalmPilot is the most popular and best supported. Linux supports Automatic Power Management (APM). There can be problems with sus- pend/resume features not working correctly; there can be problems with the graphics modes being restored properly for X (you may have better luck if you switch to a text console before suspending) and you may need a DOS partition for the suspend to disk feature to work. Some laptops do not allow you to have the floppy and the CD-ROM present simultaneously, which can make installation tricky (although most newer models probably support booting off of CD-ROM). Installation Installation of Red Hat Linux, which is included on 2 CD’s in the back of this book, is covered in The Official Red Hat Linux Installation Guide, which is available in HTML on the Net at ftp://ftp.reddat.com/reddat/reddat-5.2/i386/doc/rhmanual/ or on the enclosed Red Hat Linux CD-ROM in the directory /doc/rhmanual/. If you wish to use a different distribution, consult the documentation that came with that distribution. I recommend making a complete log of the machine configuration, the choices made during the installation, and all commands needed to install any packages you may have installed later. This is a nuisance at first but becomes very valuable when you want to install a second system, upgrade, or reinstall a system after a crash or a security compro- mise. Copy this log file offline and/or offsite or make printouts periodically. I normally log this information in a file called /root/captains-log as executable shell commands, as shown in Listing 2.1. If I edit a file, I record the diffs as a “here document” (see the
0472316072 CH02 7/26/99 2:01 PM Page 35 Setting Up a Development System 35 CHAPTER 2 bash man page) piped into “patch.” One very important thing to log is where you down- loaded code from; I do this as an ncftp or lynx -source command. LISTING 2.1 SAMPLE CAPTAINS LOG # First, lets introduce some of the commands we will # be using. The commands marked with “***” will be # covered in detail in later chapters. Refer to the # bash man page or the man page # # cat - copies its input to its output # diff - compares two files *** 2 # patch - applies the changes in a diff *** DEVELOPMENT SETTING UP A # ncftp - ftp client program # lynx - text mode web broswer SYSTEM # tar - pack and unpack tar archives # cd - change current directory # make - drives the compilation process *** # echo - display its arguments # echo hello, world - says “hello world” # # These are some examples of shell magic, see the bash # man page for more details: # # - marks a comment line # foo=bar - set variable foo equal to bar # export FOO=bar - similar, but subprocesses will inherit value # echo $(foo) - substitute $(foo) into # xxx | yyy - pipe output of command xxx into command yyy # xxx >yyy - redirect the output of command xxx to file yyy # xxx >>yyy - same, but append to file yyy # xxx <yyy - redirect input of command xxx from file yyy # xxx - Line continuation character “” # yyy - .. continuation of above line, i.e xxxyyy # xxx <<...EOF... - “here document” - runs the program xxx # line1 - .. taking input from the following # line2 - .. lines in the script up to the line # ...EOF... - .. which begins with “...EOF...”; ### ### Gnozzle ### # This is a sample captains-log entry to install # a ficticious package called gnozzle # datestamp produced using “date” command: # Mon Feb 22 21:39:26 EST 1999 continues