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.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide