Portables, Laptops, Notebooks, Sub/Mini-Notebooks, Palmtops and various other instantiations of the breed, or variations on the theme, are becoming a ubiquitous part of modern computing. So much so that Sun Microsystems and IBM are happily boasting about the Solaris/Thinkpads being carried on NASA Space Shuttle missions.

Naturally the question will arise as to how does one go about operating Unix on such machines ?

The simplest approach is to hunt around and find whatever is the current flavour of laptop SPARC, Alpha or other architecture using a native Unix variant. This is an uncomplicated strategy, which yields the desired result without the delights of an adventure in hardware and systems integration. Alas like all simple strategies, it has its difficulties, and in this instance it is dealing with the company IT manager or accountant who will no doubt be demanding an explanation of the cost on the purchase order.

So those who are fiscally challenged, must revert to the somewhat more interested strategy of acquiring one of the plethora of Intel based laptops, and installing an Intel port of Unix on the machine.

Why are laptops interesting ? Because they represent the last refuge of the semi-proprietary Intel machine.

Of the Intel based hardware market, laptops form the fraction which is most frequently endowed with vendor specific oddities.These range from peripherals, peripheral controllers, register mappings, embedded I/O to graphics adaptors. This is not to say that any laptop you pick is going to be a wholly proprietary piece of hardware - rather that any laptop you pick is likely to have one or more oddities about it which do not mesh exactly with the industry standard (with apologies to the few vendors who do try to standardise).

The oddities in the hardware used in laptops can be grouped into several categories:

From a strictly technical perspective, the big challenge with laptop designs is cramming everything which is needed for a system into a single board, which packages into a very small footprint and very tight volume, with internal cooling capacity which is very poor in comparison with desktop or deskside machines. The end product will have to withstand a shock and vibration environment which is never seen in static systems. Power consumption is a "do-or-die" performance issue in laptops.

Having had the pleasure of designing some SPARC motherboards in a previous life, I am in many respects sympathetic to the plight of the laptop designer. He/she has without any doubt the most challenging task a computer hardware designer can possibly have in the packaging game: make it small, make it robust, make it reliable, and still get decent performance out of it.

The consequence of these requirements is that many laptop designers resort to cutting their own custom Silicon for motherboard designs, since the standard chipsets made by mainstream vendors are frequently too big, and often also too capable for the task. Indeed, why should a designer use a bus adaptor or memory controller which has several times the slot capacity needed ? This eats into power consumption and board area, both of which are critical performance parameters for a laptop.

Here is of course where difficulties begin to arise. A custom chipset for a laptop motherboard may or may not religiously adhere to the architectural specifications and established design conventions of a desktop/deskside machine motherboard. This may be due the designers not having prior experience in the latter, and thus groping in the dark (not uncommon in this day and age of lowest bidder hiring policies), or it may be due to something as trivial as running out of gates or pins in/on the ASIC type in use, and thus having to multiplex these, or otherwise fudge them. The competitive pressures of beating other vendors in both the performance and the price game can have an overwhelming influence upon a designer, who is by definition subjected to considerable pressure to push a product out as quickly as possible.

Another factor must not be overlooked. The laptop market is still in many respects a niche market, aimed at professionals, and the commercial pressures for high levels of DIY commodity hardware integration basically do not exist. It is indeed in a vendor's best interests not to make the product highly compatible, since a client may buy somebody else's peripheral or I/O adaptor.

Whatever the underlying reasons may be, the laptop of today is very frequently an idiosyncratic little beast which may or may not be agreeable to open source operating systems. The laptop vendor will write their own Windoze drivers and "kernel" tweaks, and thus provide the client with a turnkey solution to the problem.

For the serious Unix user, i.e. the genuine computing professional who needs to run more specialised tools, rather than Word, Powerpoint and Excel, the laptop can present an interesting challenge.

Clearly the strategy of going out and buying the nicest looking and best priced laptop on the market may or may not result in something which can run Unix properly. Many times I have had to console hapless users who come to me with the same problem, again and again: "When I try to install Linux/FreeBSD/Solaris, XXX or YYY barfs on me !". Of course the cruel and simple answer is: "You should have checked it out before you bought it !"

Assuming that this situation has transpired, should we consider trading in the laptop for a different type, or do other measures exist which can be taken ?

The answer is yes. Linux, FreeBSD and Solaris, the three most commonly used Intel hosted Unix variants all have provisions or upgrade kits for many widely used and idiosyncratic laptop features. Odds are that with a bit of footwork, and the inevitable late hours, one of three can be made to work properly. And if Murphy prevails, and the laptop is indeed so oddball that none of the three can be made to work, then there is always the option of trading it with some religiously committed Windoze user who just can't bear to part with gimmick A or gimmick B on the machine.

Where are problems likely to arise with a laptop ? We we now explore the most frequent problem areas and discuss the various options available for the FreeBSD and Linux users, seeing that the latter are the most likely candidates for installations, and the FreeBSD PAO and Linux laptop code packages contain tools, drivers and setup information to deal with likely problems.

Power Management

Most laptops implement various levels of compliance with the MS/Intel Advanced Power Management standard (http://www.intel.com/IAL/powermgm/powermgm.htm), which is intended to be closely integrated with the machine's BIOS.

Installing the standard OS release is likely to be inadequate to get this to work properly.

To support APM properly the OS kernel must know about APM and map the appropriate part of the hardware physical address space into memory. This can be a problem with many laptops since the APM 1.1 implementation in the BIOS or the memory mapping hardware is buggy, and unable to provide 32-bit protected mode access. Various workarounds exist and are detailed in the Linux and FreeBSD literature.

Providing that the hardware and BIOS implementations are reasonably robust, then the building of a suitably configured kernel solves the problem. For FreeBSD this means compiling in the apm0 device, configuring apm_enable in /etc/rc.conf and making sure that /dev/apm or /dev/apm exists. The Linux kernel requires that CONFIG_APM_POWER_OFF be configured in.

Providing that the hardware is not too buggy, and the kernel configured properly, then various applications can be used for power management. FreeBSD users can use apm, zzz, xbatt, while Linux users can install the APMD toolset, or suspendd, apmcd and apmd.

Assuming all is installed properly, configured properly, and the hardware isn't broken by design or misconfigured at a BIOS level, then the laptop's APM facilities for hibernation or sleeping can be used without any serious restrictions.

Known problem areas can be internal sound "card" hardware causing interrupt clashes, and X servers hanging after an apm -s status request is made.

PCMCIA Hardware

Laptops are the domain of the PCMCIA card, but configuration can frequently be an issue with Unix. For a standard device to be found, a suitable driver must exist in the kernel and the card be configured at an address and interrupt level which the kernel expects. PCMCIA probing and configuration in both FreeBSD and Linux is done a little differently.

The FreeBSD PAO kit includes a /etc/pccard.conf database and a pccardd daemon, and the latter uses the former to probe out the PCMCIA devices after the kernel has booted. Linux employs an analogous scheme, using the /etc/pcmcia/config database and the /etc/init.d/pcmciam program.

Problems most frequently arise with misconfiguration of interrupts.

Graphics and the X11 Server

Getting the X11 server to run in the desired mode with an arbitrary graphics adaptor is a frequent problem with all variants of Intel hosted Unix. When doing this on a desktop/deskside machine, there is always the fallback option of pulling the card and fitting one with a better behaved chipset.

With laptops this is mostly not an option, since the graphics adaptor is typically embedded within the motherboard and will also often be hardwired into the address space and interrupt structure. Therefore, getting it to behave may require the full process of figuring out which chipset is being used, ie RAMDAC and video clock chip.

Three basic choices are available to the FreeBSD or Linux user - either run with the public domain XFree86 server, or get the commercial XiG/Xinside (http://www.xig.com) server, which comes in a laptop optimised variant, or the commercial Scitech server. XiG claim support for no less than 600 graphics chipsets, and supply servers for Linux, Solaris and FreeBSD.

If we choose to do battle with using the XFree86 server, which is the standard bundled fare with FreeBSD and Linux, then it boils down to proficiency with the Superprobe tool and patiently playing with the system until it all behaves as intended. Providing that the graphics chipset in use is not highly exotic, then odds are it can be made to work. If it is exotic, then the fallback position is to go for one of the commercial X11 servers.

In general, the standard caveats for getting an X11 server to run will apply.

Keyboards and Meezes

Some laptops may employ nonstandard mappings for some keys. This can typically be remedied by the use of a customised keyboard mapping with xmodmap or loadkeys.

Most modern laptops have dispensed with the mouse and employ embedded trackballs, touchpads or other such devices. Typically these will require a suitable driver in the kernel, and appropriate configuration of the X11 server. Examples are the Synaptics touchpad driver for Linux or the Linux Compaq Concerto Pen Driver, both available on the W3.

The fallback position is to usurp a spare serial port and employ an external serial mouse. Given the often cumbersome handling of embedded mouse substitutes, this may be the preferred choice for many users.

Infrared Ports

Infrared ports are becoming quite common with contemporary laptops. The come in two basic variants, the "standard" 115.2 kbps incarnation, and the "fast" 4 Mbps incarnation. The former is typically integrated to appear as 16550A serial chip, and is configured into the kernel as an additional serial device.

The "fast" Infrared port can be problematic, since the driver chip may or may not be supported. Linux provides a package which supports the NSC PC87108, Winbond W83977AF, and Sharp UIRCC chips, and provides both kernel and utility support.

A caveat with IR interfaces is that the machine to be connected to must be running the same protocol as the laptop. Any proprietary schemes are likely to be incompatible.

The Linux IrDA-Utils toolset provides the irmanager daemon, the irdaping test tool, the gnobex GNOME GUI for the IrOBEX protocol, and supports the IrCOMM protocol.

Internal Modems

Internal modems in laptops can be a headache. If they are implemented as PCMCIA cards, odds are a standard type can be found. Types with other, more proprietary, interfaces may be impossible to get running without a type specific driver.

Typically internal modems appear as serial ports, and thus some care should be taken with configuration. The standard caveats for internal modem installations on deskside/desktop machines apply.

Installation and System Tuning

Both FreeBSD and Linux laptop kits include a laptop bootable floppy disk to be used with the installation CD-ROM. This assumes the laptop has both an internal CD-ROM and floppy disk drive. If this is not the case, some workarounds exist and are documented.

The installation method is analogous to that on standard systems. The laptop is booted off the floppy and the OS loaded off the CD-ROM. Once the OS is loaded, the typical approach is to configure in the laptop specific features using the post-installation tool. Providing that there are no oddities in the laptop, this should be a fairly straightforward process.

Once the OS is installed, booting and running properly, and all of the standard devices found and shown to be working, we then proceed to do the usual post-install chores such as setting up accounts, configuring the network etc.

The final phase of the installation will be getting the X11 server up and properly configured.

Because a laptop is likely to be short on memory, with only 32 MB in many instances, it is desirable that we make a generous allowance for swap space. Allocating 128 MB or more to swap (during installation) is not a bad idea. A good rule of thumb is to set the swap space size to four times that of the memory. If more than one disk is installed, then slicing the swap space across two spindles in a good idea.

Once the installation is up and running and all problem areas fixed, we can concern ourselves with system tuning. Why system tuning ? Because laptops tend to be under-resourced in comparison with desktop/deskside machines. Less memory, slower CPUs, smaller disks, frequently smaller peripherals, shallower buffering in adaptor hardware. All of the aforementioned side effects of cramming hardware into a minimal volume.

The starting point is kernel configuration. Ideally we should rebuild the kernel to a minimal configuration, and hack out every device and pseudo-device which is not on the machine. This can frequently save up to a Megabyte of memory, memory which is often statically allocated to the kernel and not swapped.

The next step is to figure out which tools and utilities we do not need, and delete them. While this is best done at installation time, less experienced users may want to leave it for later.

If interactive performance, or CPU speed, are major issues, then consideration should be given to using the XiG X11 server due to its high speed.

These are the most practical tuning measures available. Unlike desktop/deskside machines, where we can play with the hardware, laptops are basically inflexible.

A final note in this context is that users who are seriously mobile should consider installing a Mobile IP agent on the laptop, and on a local host.

Choosing the Hardware

While discussing the subject of installations, it is worth reiterating some basic points on choosing suitable hardware.

To avoid the aches and pains of DIY integration job, there is much to be said for doing the homework and checking out the FreeBSD PAO website (http://www.jp.FreeBSD.org/PAO/), the Linux on Laptops website (http://www.cs.utexas.edu/users/kharker/linux-laptop/) and the Solaris on Intel website (http://www.sun.com) to familiarise oneself with the technical issues, and download lists of laptops which are known to work with any or all of these operating systems.

This is a very cheap means of minimising if not completely removing the risks of incompatibility. The laptops with the desired performance and features can be culled from this list, and the vendors appropriately haggled with for price.

Laptop hosted Unix is certainly a much messier proposition than installation on desktop/deskside machines, but in general, should proper care be taken then a fully functional system can be implemented.

The payoff, other than avoiding the aches and pains of the proprietary OS world, must surely lie in the sheer astonishment of the lay users when they see a laptop running a real operating system !