The Wonderful World of Linux 2.2

As any kernel developer can surely tell you, the advent of Linux 2.2 is imminent. Linux 2.1 is approaching near astronomical version numbers in its slow march to completeness, 2.1.108 as of this writing, and all eyes are looking toward the day when 2.2.0 will ship standard in the various distributions. Even if you don't actually follow the Linux kernel version by version, 2.2 is an important milestone to understand. This article is my take on the Linux kernel developments of late, with a significant bias towards x86, the Linux I use most often at home.

Development in the world of Intel chips is fast and interesting to follow if you have nothing better to do. Merced, Celeron, MMX—the names of Intel technologies float past to be replaced by new cutting-edge technology. (Whether or not these technologies are worthwhile is debatable.) In addition, AMD, Cyrix and other companies have become solid competitors in the market, and each has its own little optimizations, quirks and bugs. It is a mess to keep up with.

Linux 2.2 will be the first stable Linux version to support optimizations for each of these chips and a selection for the processor vendor in the kernel configuration tool for even better fine-tuning. Perhaps even more importantly, Linux 2.2 (and later revisions of 2.0 for obvious reasons) supports bug fixes and workarounds for widespread processor bugs including the infamous F00F Pentium bug. Other bugs that can't be worked around, such as several AMD K6 bugs, are reported during startup.

Merced hasn't arrived yet and probably isn't immediately forthcoming; however, Linux 2.2 has already been ported to SPARC64, Alpha and other 64-bit platforms, so the infrastructure for a 64-bit native kernel is (happily) already in place. There are, of course, other obstacles that would have to be overcome before Linux/Merced could be released, but having a 64-bit ready kernel is an important step.

Multiple-processor machines will now operate much more efficiently than they did in Linux 2.0, with problems such as the global spinlock removed. Up to 16 processors are supported (the same as with 2.0), but the performance difference should be amazing. Also, there is now greater support for the IO-APIC on Intel boards that will make SMP generally better supported.

In terms of other ports, Linux 2.2 will feature improved support for a large number of “mainframe” machines such as SPARC, SPARC64, ARM and Alpha machines. As for “desktop” machines, Linux 2.2 has been ported to both m68k and PPC flavors of the Macintosh with varying degrees of hardware support. (You can expect that support will only get better as we approach 2.4 or whatever comes next.)

On somewhat of a tangent, there is continuing work to support a subset of the Linux kernel on 8086, 8088, 80186 and 80286 machines. This will not likely be usable in time for 2.2, but is something to look for in the future.

Although somewhat less crucial, Linux 2.2 will support a much larger percentage of the existing x86 computers with the addition of complete support for the Microchannel bus found on some PS/2s and older machines.

In addition to hundreds of minor patches to the bus system, including many new PCI (protocol control information) device names, larger improvements have taken place. PCI, in particular, has undergone several major changes. First, the PCI device reporting interface has been changed and moved to allow for easier addition of new information fields. This particular change doesn't spell much of a difference for an end user, but it makes the lives of developers much easier. Additionally, it is now possible to choose whether you wish to scan your PCI bus using your compatible PCI BIOS or through direct access. This feature allows Linux 2.2 to work on a larger set of machines: several PCI BIOSes were incompatible with the standards and caused booting problems.

Sadly, little kernel support is available for Plug-and-Play ISA devices. While that would be a great addition, a few problems with the currently proposed system will need to be resolved at some time in 2.3. Fortunately, a great user-level utility, isapnp, is available for setting up PnP devices; it requires a tad more work than I'd like, but gets the job done in true Linux fashion.

As far as Linux IDE is concerned, very few obvious changes have been made. The most obvious one is that it is now possible to load and unload the IDE subsystem as a module, just like SCSI. This has the added bonus of allowing use of a PnP-based IDE controller. For less bleeding-edge machines, the updated IDE driver now supports older MFM and RLL disks and controllers without having to load an older version of the driver. Linux 2.2 also has the ability to detect and configure all PCI-based IDE cards automatically, including the activation of DMA bus mastering to reduce CPU overhead and improve performance. Finally, more drivers have been developed for controllers that are buggy or simply different. It is amazing how even excellent things can continue to become better.

Elsewhere in the IDE world, parallel-port IDE devices have become more common, and are for the most part now supported by Linux 2.2. It is a good assumption that many devices currently not supported will be added as 2.2 progresses.

Unfortunately for devices such as rewritable CD-ROMs, there are still instances where you need to use the newly-added SCSI-emulation driver as a kludge for support. I don't like it, but that's the way it is. This limitation may be removed in future versions of the CD-ROM driver, but will likely still be present when 2.2.0 ships.

The SCSI subsystem's main improvement has been the addition of many new drivers for many new cards and chip sets—too many to even begin to name.

The bad news concerns an ongoing effort to support USB (universal serial bus) and USB devices; so far, any progress made in this area has not been included in a Linux 2.1 release. While this could change before the official 2.2 release, it is unlikely that such a large feature would be included this close to release.

Nothing much is new on this front; Linux has always had incredible support for these basic building blocks. The parallel-port driver has been rewritten with cross-platform issues in mind, and thus what was once just a “Parallel Port” is now a “PC-Style Parallel Port”, functionality-wise. Note that the naming convention used to label parallel ports has changed, so you may find your lp1 has become your lp0. Distributions should allow for this change automatically.

Serial support is chugging along as well as it always has, with one notable difference. Previously, a serial device such as a modem involved two devices, one for call-in and one for call-out (ttyS and cua, respectively). As of Linux 2.2, the two are combined in one device (ttyS), and accessing the cua devices now prints a warning message to the kernel log. On the bright side, Linux 2.2 includes support for having more than four serial ports, it allows serial devices to share interrupts, and it includes a number of drivers for non-standard ports and multi-port cards. My only complaint about serial support is its lack of support for the standard methods used by modules to pass device parameters at module-load time via the modules.conf file and kmod. Instead, these parameters are set using the setserial command.

Thankfully, the hodgepodge of hundreds of CD-ROM standards has solidified behind the “standard” of ATAPI CD-ROMs. This reprieve has given developers time to completely rewrite the CD-ROM driver system to be more standardized in terms of support. Small, quirky differences between the individual drivers have now all been fixed for better support.

Rewritable CD-ROMs aren't supported as well as I would like. SCSI CD-ROMs are well done, but IDE drives may require the SCSI-emulation kludge driver. This limitation may be removed in a future version of the CD-ROM subsystem, but is something that must be coped with for now.

Floppies are working as great as ever. New developments have been made in terms of large volume floppies, and it remains to be seen whether or not all of these will be supported. The so-called ATAPI floppies already have a driver.

IOMEGA's Zip drive, an increasingly popular storage solution, is fairly well-supported under Linux 2.2. These beasts come in two versions: SCSI and parallel. Under SCSI, the Zip drives are supported just as any other disk would be. The parallel version of these drives actually uses a kind of SCSI-over-parallel protocol, also supported in Linux 2.2. Other IOMEGA solutions such as DITTO drives may also be supported using the ftape drivers.

The issue of DVD is something for which no one seems to know the answer. It is highly probable that DVD is already supported in some way, most likely through the IDE ATAPI driver interface. DVDs are much like CD-ROMs. If a standard emerges that Linux 2.2 does not support, it is fairly certain that it will be added sometime during the 2.2.x stabilization cycle following the initial release.

Other removable media may or may not be supported under Linux 2.2. If the device in question connects through the parallel port, it is possible that it is supported using one of the parallel-port IDE device protocol modules included in the kernel.

At long last, the sound code has been partially rewritten to be completely modular from start to finish. Distributions will be able to more easily include generic sound support out-of-the-box for their users as well as making it easier for the rest of us to load and configure sound devices (in particular, pesky Plug-and-Play ones). Many new sound devices are supported as well, and it looks as if this is one area where Linux will truly improve in the next year.

One notable defect is the lack of support for the PC internal speaker, if only for completeness. Then again, Windows doesn't do it either, so who am I to judge?

Linux 2.2 now has amazing support for a growing number of TV and radio-tuner cards and digital cameras. This is truly a bleeding-edge addition to 2.1's roster, so some uncorrected problems may remain, but it is reasonable to assume they will be fixed in time. In my opinion, this is just an amazing area for Linux to be in at all.

Linux 2.2's backup- and tape-device subsystem has not changed much since the 2.0 release. More drivers for devices have been written, of course, and substantial improvements have been made for backup devices that work off of the floppy-disk controller (including the IOMEGA DITTO).

Rewritable CD-ROMs have become a popular solution for backing up data, and they are supported under Linux 2.2 either natively or by using the SCSI Emulation driver. There are still remaining problems in this regard—see my note above on CD-ROMs.

Joysticks will be better supported in 2.2, including a large number of new joysticks and ones with an inordinate number of buttons.

Mice in 2.2 aren't very different from those in 2.0. As in 2.0, some inconsistencies regarding mouse support will be addressed in the future. For the most part, mouse control is provided through a daemon external to the kernel. Some mouse drivers deliberately emulate a Microsoft-standard mouse. The reasoning behind this is obvious, but it would be nice if it was decided on in one way or the other. My only other complaint is that Microsoft mice with the little spinning wheel have no real support, not even using the wheel as a third button. Again, that really isn't a kernel issue. No big problems are present, though.

Additionally, several other input devices are now supported under Linux 2.2, including some digitizer pads. If your devices emulate a mouse (as many do), it is already supported by Linux 2.2 (and, in fact, by Linux 2.0.)

Many smaller additions have been made to the Linux 2.2 kernel to make it more robust, and many of these honestly don't fit in any other category. The loopback driver, which allows you to mount disk images as if they were real drives, has been improved to support better encryption, although there may be issues here with U.S. laws. Also, support is now provided for “initial RAM disks” to allow a Linux user or distribution to boot a kernel with no hardware support compiled in, and to load the required device drivers from a small RAM disk. This is useful for systems with Plug-and-Play devices that can't be accessed until after a user-mode configuration program is run. A driver has also been provided in Linux 2.2 to access CMOS (complementary metal oxide semiconductor) RAM directly for whatever reason. A similar driver to access the flash memory of many BIOS was not put into 2.2, but may be included in Linux 2.4. It may still be necessary to boot DOS from a floppy to update your computer's flashable BIOS. Finally, Linux 2.2 allows you to share raw disk images over a network.

Linux 2.2 has a wide array of new file systems and partition types to provide interconnectivity. For the Microsoft nut, Linux will now read (and maybe write) NTFS (Windows NT) partitions and Windows 98 (and Windows 95 OSR2) FAT32 partitions. Linux 2.2 also understands Microsoft's Joliet system for long file names on CD-ROMs, and a new type of extended partition invented by Microsoft.

Drivers to read and write Microsoft and Stacker compressed drives are being developed but are not yet included in the kernel.

For Macintosh connectivity, an HFS driver for reading and writing Macintosh disks has been included. HFS+ and older Macintosh file systems are not yet supported. Macintosh partition tables can also be read by the kernel; this allows Macintosh SCSI disks to be mounted natively.

Sadly, OS/2 users will still not be able to write to their HPFS drives. Some updates have been made to the HPFS driver to support the new “dcache” system, but not the hoped-for overhaul.

If there are any Amiga users left, they will be pleased to know that the FFS driver has undergone some minor updates since 2.0. This may be especially useful if the new generation of PPC Amigas uses the same disk format.

For connectivity to other UNIX systems, Linux 2.2 has come forward in leaps and bounds. Linux 2.2 still includes the UFS file system which is used on BSD-derived systems, such as Solaris and the free versions of BSD. Linux 2.2 can also read the partition-table formats used by FreeBSD, SunOS and Solaris. For SysV-style UNIX systems, Linux 2.2 features an updated version of SysVFS. It can also read Acorn's RiscOS disks. Finally, Linux 2.2 features an updated version of the ever-popular Minix file system that can be used for small drives and floppies on most UNIX systems. With so many incompatible formats and Linux 2.2 reading so many of them, it is amazing anyone ever got any work done.

In other news, support for “extended” drives (the format used by much older versions of Linux) has been removed in favor of the “second extended” file system. (This shouldn't matter to many people; Ext2 is far superior to its predecessor.) With the increased support of initial RAM disks, a “romfs” has been created which requires a very minimal amount of overhead.

While not quite a file system, Linux 2.2 includes enhanced support for stretching a file system across several disks transparently. At present, this support can be used in RAID 0, 1, 4 and 5 modes as well as in a simple linear mode.

Perhaps the most surprising and cutting-edge addition to the Linux kernel for inclusion in version 2.2 is what is called the “frame-buffer console” driver (or fbcon, for short).

Previously, the Linux kernel (for Intel-based machines) understood and manipulated the video devices only in text mode. Graphical support was to be provided by two other systems: svgalib for console-based graphics and a specialized X server for window-based graphics. This kludgey system often required configuration information to be repeated, and each system supported only a limited slice of the myriad of video devices in common use.

Since this addition is rather new, it remains to be seen whether it will truly replace the previous long-standing duality. Unfortunately, it will be nearly a year after Linux 2.2 ships before this new system is robust enough to support the cards and technologies we already take for granted as working. My personal opinion is that this is the right idea, but I will hold judgment until I see exactly how far Linus and the developers decide to take this feature.

It is also possible to remove support for “virtual” terminals as provided by the kernel. This allows very memory-conscious people to save just a tad more.

Although unimaginable to the desktop user, Linux can now work even better on systems that do not actually include any sort of video device. In addition to being able to log in over serial or networked lines, as Linux 2.0 and previous Linux versions allowed, it is now possible to redirect all the kernel messages (usually sent to the console directly before any hardware was initialized) to a serial device.

Linux 2.2 supports a large array of solutions for amateur radio operators, including a large number of enhancements from Linux 2.0. Unfortunately, this is not my forte—I've never even seen a Linux-based amateur radio station.

I don't have much experience here; I've been using the same network cards in all my machines for several years. However, it is not hard to see that the number of Ethernet and ISDN devices supported in Linux 2.2 has risen sharply. I have been told that newer solutions such as cable modems are also supported.

On the low end, not much has changed. PPP, SLIP, CSLIP and PLIP are all still available for use. I guess some things don't need much improvement. Each of those drivers has been updated in one way or another.

My only gripe in this regard is the continued non-support of so-called Winmodems. Not that I blame Linux for their absence (making modems that are 80% software is a dumb idea anyway), but the idealist in me hopes that one day these pesky devils will be supported like their more usable cousins.

On the protocol front, a lot has happened that I simply don't understand completely. The next-generation Internet protocol, IPv6, has made an appearance. SPX, an alternate version of IPX, is new as well. DDP, the protocol of choice for AppleTalk networking has also been added. Just as you would come to expect by now, the existing protocols have been improved. I only wish I had the need to use some of this stuff.

The list keeps going, however. Linux 2.2 will have an excellent new networking core, new tunneling code, a new firewalling and routing system called “ipchains”, support for limiting bandwidth consumption and a ton more.

File- and printer-sharing protocols have also been markedly improved and enhanced. SMB, the protocol for accessing MS Windows-based shared file systems, has been improved with bug fixes and the like. If you are a fan of NetWare, you'll be happy to know that Linux 2.2 supports a large number of improvements in this area, including access to two different kinds of NCP long file names. Trusty NFS has also been improved, both at the server level and the client level. Finally, those guys over at Carnegie Mellon University have been hard at work developing the new distributed network file system, Coda. This file system supports a large number of highly requested features, including disconnected operations for laptops, an advanced cache system and security improvements.

There's quite a lot that honestly doesn't fit into any of the categories above.

For one, the old system of loading “in and out” drivers (called modules) has been replaced with a system that doesn't require a separate daemon and allows for a smaller memory footprint. This is the kmod system which replaces the kerneld system. I have to say I think this is a good thing.

Also, the old method of access to file systems has been replaced by the “dcache” system, which may be the fastest virtual file system for any OS currently on the market. It makes you proud to support Linux.