Date: Thu, 07 Oct 1999 00:54:08 -0400
From: Joseph Pranevich <jpranevich@lycos.com>
To: lwn@lwn.net
Subject: Updated WWoL


Wonderful World of Linux 2.4 (10/02/99) "Final" 
                                       
A long time ago, in a galaxy not too far from this one, I wrote an article.
It wasn't much, just a laundry list of the new and improved features of
Linux 2.2. That was a long time ago and the newness of Linux 2.2 is
beginning to wear off; it's even lost that new kernel smell. And so with
anxious eyes, we set our sights towards the future of Linux: Linux 2.4. In
the Linux world, it is uncommon to announce release dates; new versions
are released when they are ready and not before. With that said however,
Linux 2.3 has entered into a feature freeze and looks to be ready for the
masses sometime around Christmas.
   
Before we move into the meat and bones of the situation, I always like to
step back for a moment and say a few things. Linux 2.2 marked a major
milestone in Linux's evolution: it was the first kernel release which
truly caught the eye of the all-seeing media. No longer would just obscure
computer publications trumpet the latest and greatest from the Linux world,
but mainstream publications as well. With the attention has come the
inevitable FUD (Fear, Uncertainty, and Doubt) that we prayed would never
come, but out of this media molasses we have emerged as a stronger
community. While many of Linux's weak points were trumpeted and many
members of the Linux community despaired, there were still the legions of
kernel hackers that worked day and night to take those weaknesses,
acknowledge them, and work to fix them. I think they've done wonderful
job.
   
As a side effect of the increased media attention, many members of the
media chose to use my original article as a guide, a reference to the new
changes and features in Linux 2.2 in the absence of any official press
release. To be honest, I was flattered. I do ask however that you cite the
source whenever possible (both myself and the community who made this
document possible) and if you require any clarifications, please do not
hesitate to email me at the addresses below with your questions. If you
would like to reprint or translate this article in full or in part in any
medium, please email me at the address below so that I can be aware of
your work before you do so. I will make a list of translations that I am
aware of available.
   
This is still a draft document and may not be 100% accurate. Caution is
advised. Also, new subsections have been added based on comments I
received. I may keep or removed them later depending on user input. Some
of these subsections will become full-blown articles at some point in the
future. Please let me know what you think.)
   
Now, without further ado, Linux 2.4. This draft of the WWoL2.4 is
subtitled the "final" edition, whatever that means. Depending on
feedback, there may be cause to release one or more other "final"
releases. As there is a feature freeze in place, I don't expect there
to be any new additions to the kernel before release.
  
Joe - jpranevich@linuxtoday.com 	(Home) 
      jpranevich@lycos.com 		(Work)

< Many thanks to linuxtoday for providing me with the spiffy email addy.
Other than the email, I'm in no way associated with nor speak for Linux
Today. This work also has absolutely nothing to do with Lycos, my
employer. The views here are all mine and this article does not constitute
an endorsement from Lycos or any other such thing.  They are however a
pretty damn fine company to work for. >

--
   
Linux Internals

Linux 2.2 was a great improvement over Linux 2.0. It supported many new
file systems, it supported a completely rethought caching system for file
names, and it was much more scalable than Linux 2.0. Linux 2.4 will build
on the great advancements provided under Linux 2.2 to become an even
better platform for desktop, server, and embedded tasks. However, it is
the intent of the Linux kernel developers to get Linux 2.4 into the hands
of the end users more quickly. To meet this goal, Linux 2.4 will
understandably not be as different from Linux 2.2 as Linux 2.2 was from
Linux 2.0. I think you will agree however that the advancements in Linux
2.4 will be just as noteworthy as previous versions. (Or else I wouldn't
need to be writing this!)
   
What, at the core, is the Linux kernel? Just as the kernel is the heart of
the Linux (or GNU/Linux or whatever) Operating System, the kernel itself
can be divided into core and non-core parts. Linux is much more than just
a collection of assorted device drivers, as any operating system must be.
It's what binds these drivers together into a cohesive unit that matters.
It's the scheduler, the resource allocator, the virtual filesystem layer,
memory management, and so many other unsung features that are the real
heroes of the Linux world. These are the portions of the Linux operating
system that really define what is Linux because on every platform that
Linux has been ported to from i386 (Intel-compatible PC), to ARM (embedded
devices), to Sparc64 (high-end servers) this code is the same. In many
ways, this "heart" of Linux 2.4 is different than Linux 2.2's and most of
the subsystems that I just listed have been changed in one way or another.
   
Linux 2.2 and earlier Linux's included a base resource management system
which was used rather bluntly to allocate and keep track of IO ports and
IRQ lines and the other limited niceties of computer architectures.
Unfortunately it was deficient in a number of important ways which proved
crucial to the needs of a modern desktop operating system. The new system
under Linux 2.4 includes a much more generic implementation which allows
for nested resource groups, removed the dependencies on pre-defined
resource types, and otherwise made it easier to use for a majority of the
tasks required by driver developers. Additionally, this has laid the
groundwork for ISA PnP support which is discussed more fully later in this
article. This quick hack by Linus will probably be one of the most
influential changes to go into the 2.4 kernel.

The virtual filesystem layer (VFS) has also been heavily modified from
earlier Linuxes. Linux 2.2 featured a number of wonderful changes to this
layer that allowed for better caching and a much more efficient system
overall. However, the system in Linux 2.2 still had a number of important
limitations which were resolved in time for Linux 2.4. One major
limitation to the way Linux 2.2 handled things was its use of two buffers
for caching: one for reading and one for output. As you can imagine, this
made things very complicated as the kernel developers had to code with kid
gloves to always ensure that these caches were in synch when they had to
be. Linux 2.4 brings this wall completely down by removing the multiple
cache system and putting all the work into a single page caching layer.
This change makes Linux 2.4 more efficient, the code is easier to
understand for developers, and the amount of memory needed for the caches
have been split roughly in two. During the course of this rewrite, many
race conditions (errors caused when multiple processes "race" for access
to unprotected variables) were removed and the code streamlined to allow
significantly better scaling to higher-end systems and disk writes to
happen faster when multiple volumes are involved.
   
One common problem with Linux 2.2 that interfered with high-end (Intel?)
machines was its process limitations. Linux 2.2 only allowed you to have
1024 processes or threads running at once. With high-end systems with many
thousands of users, this could become a problem very quickly. Linux 2.4
has gotten rid of this relic and implemented a scalable limit which can be
configured at run time and is only limited by the amount of memory in the
system. On high-end servers with as little as half a gigabyte of RAM
installed, it is easily possible to support as many as 16 thousand
processes at once. Other users have reported being able to run many more
than that on their specific systems. This was one of the major bottlenecks
that kept Linux out of the Enterprise markets.
   
In terms of memory consumption, Linux 2.4 will require approximately the
same amount of memory as does Linux 2.2. Some subsystems have been added
or expanded and some have been streamlined. Some obsolete code has been
removed. There are even certain cases where some systems will require less
memory than Linux 2.2! It should be noted also that Linux 2.4 will also
support /more/ memory than its predecessor. As of Linux 2.4, up to 4
gigabytes of RAM will be supported on Intel machines. This additional RAM
will not be treated in exactly the same way as lower RAM (due to Intel
design features) but will however be used by many in-kernel structures.
   
Binary Types
  
One often overlooked portion of the Linux kernel is the program loader;
the bit that takes your programs, loads them properly, and runs them. Many
people are not aware however that Linux 2.2 added support for a "misc."
binary loader, a flexible module designed to allow you to associate binary
types with "helper" applications in much the same way as Windows or a
comparable operating system would. This would, for example, allow you to
associate all Windows applications on your machine with WINE (Windows
Emulator) so that when you typed "./notepad.exe" the right thing would
happen. (However it is generally not a good idea to take this concept to
the extreme at the kernel level and many of the "associations" provided by
Windows would be best left handled by your window or file manager. It
would be a bad idea, for example, to be able to run "/etc/passwd" and have
it come up in a text editor.) This was considered a big win by many
because it allowed many different groups, such as the WINE and Dosemu (DOS
Emulator) groups, to publish instructions for making their programs run
"native" by the kernel.
   
Linux 2.2 and Linux 2.0 included support for running Java applications (or
rather, starting a Java interpreter/compiler when necessary) and was the
first OS to do so at the kernel level. When a java application was
executed, the Java binary loader would load up your Java interpreter with
the proper arguments. Naturally, it would be easy to implement this
functionality using the newer "misc." loader type and instructions were
provided with Linux 2.2 on how to do so. Linux 2.4 will finally put the
old binary loader to rest and all users who used the old module will have
to upgrade their configuration to make the new association.
   
Linux 2.4 will be much more dependent on the ELF format than Linux 2.2
was, although Linux 2.2 was the first version of Linux to require the
kernel to be compiled as ELF. (ELF is an advanced binary format that
includes support for multiple code and data sections, easier support for
shared libraries, and other niceties. It is approximately akin to the
Win32 format, however better designed and without nearly as much cruft.)
By more fully exploiting the ELF binary format, the kernel developers
could make some pieces of code more modular and easy to maintain. Many
types of drivers will become more "plug and play" (if I may be so bold as
to abuse that term) as they will be initialized based on how they are
linked rather than by having an explicit initialization line in the core
code.
   
In addition, there are some other noteworthy changes to Linux 2.4 that I
should mention before we move on into the specific subsystems.  Linux 2.4
will be in some ways more standards compliant than previous Linuxes with
the adoption of support for POSIX clocks and timers, allowing for non-rtc
devices to be used as clocks internally. (This would be specialized
hardware, generally.) The NFS filesystem, the standard network filesystem
used under most UNIXes, now supports most of the features of version 3 of
the protocol and Linux will better be able to communicate with machines
which communicate with this standard (this will be discussed further in
the filesystem section, below.) In addition, some minor changes were made
to the threading model and elsewhere to make things more compatible.
   
The Many Flavors of Linux

While infrastructure is the heart of the Linux operating system, it is the
parts of the operating system that are specific to the individual flavors
of Linux that are most obvious to the end users. These "arms and legs" of
the Linux operating system include all of the architecture dependent and
independent driver code which control the processors, disk drives, ports,
and everything else that provides real access to the computer. For the
purposes of this article, I will be concentrating on i386 Linux because it
is the flavor that I am most familiar. There have been great advancements
in every port since the launch of Linux 2.2 however most of these ports
are beyond my direct experience. (If there is interest in this material, I
will be more than happy to write appendixes if someone would provide me
with a list of updates to a specific port.) Since the launch of Linux 2.2,
there have been only one new port (SuperH) integrated into what will be
Linux 2.4 but this may change before release.
   
On Intel-compatible hardware, Linux 2.4 includes the same excellent
support for processors as did Linux 2.2. This includes optimizations for
386, 486, 586 (Pentium), and 686 (Pentium Pro / Pentium II / Pentium III)
processors, as well as "compatible" counterparts such as those made by AMD
and Cyrix. Additionally, Linux 2.4 will include additional support for
hardware present with modern chips. While Linux 2.2 includes support for
Intel's Memory Type Range Registers (MTRRs) to increase performance to
some kinds of high-bandwidth devices, Linux 2.4 has taken this support
even further by supporting variants common to the compatible chips. (This
includes both the double MTRRs present with AMD K7 processors and the MCR
variant preferred by Cyrix.) Linux 2.2 also included support for the
IO-APIC (Advanced Programmable Interrupt Controller) which allowed
interrupts to be spread across multiple processors in a multi-processing
system. Linux 2.4 will, as expected, take this to the next level and
support some high-end systems which actually contain multiple IO-APIC
controllers; this will allow these machines to scale even better than
before.
   
To my knowledge, the only multi-processor systems which we still do not
completely support are some very old 486 ones that mix 486DX and 486SX
chips in the same system. This is mainly because the SX chips did not
contain math coprocessors and there is some difficulty in making sure that
applications that need floating point math get to work on the right one.
As you can imagine, there isn't much call for this feature. (There may be
other buggy chipsets combinations that are unsupported, however I am not
personally aware of them.) Considering that no one in their right mind
will still be using such a system (they could easily upgrade to a chip
with a FPU), I don't consider this much of a limitation.
   
Linux 2.4 and Merced (ia64)
  
While not yet delivered to the starving masses, Intel's 64-bit replacement
to the x86 line is coming down the pipeline. While Linux 2.4 does not
include any direct support for the chip (since it is not out yet, that
would be difficult), there are multiple groups working to make sure that
there will be Linux on Merced immediately after its release. This porting
process is no doubt simplified by Linux's existing support for 64-bit
processors (including Compaq's Alpha chips and the Sparc64) which are
already merged into the main Linux tree. This means that much of the
gruntwork in making 64-bit Linux on Merced a reality (making sure that the
kernel and all its drivers do not believe that they "know" what the size
of datatypes are and how numbers are stored internally, etc.) is already
completed. (And has been for quite some time.)
   
I do not want to imply that there are no remaining problems that keep
Linux from being "perfect" on 64-bit systems; that is not the case.
However a vast majority of the difficult and subtle parts are completed
and all that remains are problems derived from a legacy world.
   
Linux 2.4 and Pre-386 Intel Chips
  
Surprisingly, I do get a number of questions about pre-386 Linux. The
answer, at least right now, is that there is no such animal. A sister
project, ELKS (Embeddable Linux Kernel Subset) is working to make a
Linux-like operating system run on these machines, including protected
mode support for chips that support it. This project is separate from
Linux-proper however and is outside the scope of this document.
   
Buses - ISA, PCI, USB, MCA, etc.

Processors however are just a small part of the guts of a computer.
Equally important to its operation is its bus architecture, the component
of the system that is responsible for (or irresponsible towards, as the
case may be) internal and external devices. Linux 2.4 has not yet touched
much on the internal workings of many of the supported busses, including
(E)ISA, VLB, PCI, and MCA except to work them into the new resource
management subsystem and fix bugs. The biggest news in this area is that
ISA PnP, the somewhat
misguided attempt to support device configuration and detection on the ISA
bus, is finally supported at the kernel level! In the future, this will
allow PnP devices to "just work" and not need any supplementary
configuration utilities to function properly.

There is more exciting news from this front however. Universal Serial Bus,
a new external bus type just now coming into prominence for devices such
as keyboards, mice, sound systems, and scanners is now supported in the
Linux kernel. At the time of this writing, the support is not 100% and
many individual and common USB devices are not supported or not completely
supported. I would be confident however that the number of devices which
are supported will only rise over time, just as we observed a similar rise
in the number of framebuffer devices that are now supported. (The
framebuffer was a new feature to Linux 2.2, see below.) Currently,
keyboards and mice are working mostly as you would expect. Support for
sound systems is coming along rapidly. Other devices, such as modems and
network cards, already have preliminary support however their drivers are
not complete.
   
In addition to USB, I2O device (Intelligent Input/Output) support, an
extension of PCI, has been added in Linux 2.4. In theory, this will allow
for more operating system independent devices and drivers to exist. Many
I2O devices are already functioning and more will be added before Linux
2.4.
   
PCMCIA support, the semi-external bus common in laptop computers, is now
supported from within the standard kernel distribution. No longer will
PCMCIA users need to download and install separate packages to get their
systems to work properly.

Linux and ISA Plug-and-Play
  
I have heard time and time again the question "When will Linux support
Plug-and-Play?" that in and of itself can mean many things and the Linux
kernel has included support for many kinds of "Plug-and-Play" devices for
several revisions. Support for ISA PnP, the Plug-and-Play specification
that works as a superset of the ISA bus, has long been a sore point for
many Linux users. I am happy to say that Linux 2.4 will finally include
direct support for configuring PnP devices although (as of this writing)
many or most drivers have not been updated to probe for their supported
ISA PnP cards.
 
Block Devices - Disk Drives, RAID Controllers, etc.

>From most user's points of view, there are three different fundamental
types of devices under Linux: block devices, character devices, and
network devices. We will discuss each of these in turn.
   
Block devices are hardware whose data can be best expressed in an array of
bytes that can be accessed individually. (This is simplified a bit.) To
use a more computer savvy term, block devices are devices that support
random access; allowing a user to seek to a specific place anywhere on the
device to read from or write to (this is also simplified a bit). Common
examples of block devices are harddisks, floppy drives, (anything that you
can imagine as a "drive", mostly.), ramdisks, etc. If a device has special
features (for example, can be ejected), it will support these extras
through ioctls (I/O controls) which any program can use. Linux 2.2 already
supports the most common types of storage media for enterprise and desktop
use including RAID controllers, IDE and SCSI disks, and many others. Linux
2.4 will build on this in a number of important ways.
   
IDE is the most common type of disks used in PCs today. Each IDE
controller actually supports two separate disks (harddrives, cdrom drives,
etc.) which appear under Linux as separate block devices. Linux 2.4 has
improved on Linux 2.2's support of IDE by more than doubling the number of
IDE controllers allowed in a system to 10. (Previously, 4 was the maximum
allowed.) This boosts Linux to a theoretical limit of 20 IDE devices.
There have also been some changes to allow for better support for DVDs and
CD-ROM changers. While it may not be ready for Linux 2.4, there is ongoing
work to allow Linux to fully support rewritable CDs and DVDs in a
transparent fashion, for the time being however these should be considered
read-only under normal circumstances but a previously formatted disk image
can be copied out to the disk directly. And finally, Linux 2.4 has access
the UDMA features of many new hardware chipsets and can work better around
the bugs present in some pieces of hardware.
   
The SCSI subsystem has advanced in Linux 2.4, the most obvious example
being in the number of new SCSI controllers supported. The long awaited
SCSI rewrite has not happened for Linux 2.4 although a major cleanup
effort is underway.
   
One idea adopted from the commercial UNIX world into Linux is the concept
of a "raw" I/O device. A raw device is one whose accesses are not handled
through the caching layer and whose actions are immediately and always
synchronous with the "hard" data on the disk or elsewhere. This idea has
many enterprise uses as it allows Linux to better maintain data integrity
in the case of a system failure for ultra-important data. Also, this
capability has been exploited by database applications which feel that
they can do a better caching job than the native filesystem. What kept
this idea from being adopted before was that commercial UNIXes did not
provide a scalable process to allocate and access these devices, rather
they required that a "raw" device node be allocated for each and every
block device on the system. After much thought and many rejected ideas,
this functionality was finally allowed in by creating a pool of "raw"
device nodes which then can be associated with any arbitrary block device.
Thus, we need only have nodes allocated for the number of raw devices that
we will be using at any one time.
   
Filesystems

Block filesystems can be used in many ways. The most common way to use a
block devices is to mount a filesystem on it. (Internally, the filesystem
code is like an overlay on the block device driver.) It should also be
mentioned that these filesystems (as well as nearly everything else) will
work with all versions of Linux and are not only applicable to i386 Linux.
   
Linux 2.4 includes all of the new filesystems present in Linux 2.2. These
filesystems include FAT (for MSDOS), NTFS (for Windows NT/2000), VFAT and
FAT32 (for Windows 9x), HFS (for Macintoshes), and many, many others. All
of these filesystems have been rewritten to some extent, sometimes a very
large extent, to support the new page caching system and will be more
efficient because of it. On the flip side however, binary-only filesystem
modules designed for Linux 2.2 will not work with Linux 2.4. (Unlike some
software firms, Linux does not generally provide for back-compatibility at
the module level. Generally, open source modules can adapt quickly enough
and binary module providers are expected to do the same or release the
code.)
   
Some users will however notice major improvements to allow for better
compatibility with other systems. OS/2 users will finally be able to both
read and write to their disks under Linux. (This change is a long time in
coming.) NT users unfortunately don't yet have that luxury unless they
wish to use an "experimental" driver which may lead to disk corruption
under certain situations. Linux 2.4 will also include a couple of
improvements designed to make it interoperate better with other UNIX-like
operating systems. Key to this is Linux 2.4's upcoming support for the
IRIX efs filesystem and the IRIX disklabel (partition table) format. Also,
support for NextStep has also improved as the UFS driver now supports its
CDROMs.
   
Users who mount Windows shared drives via SMB (Server Message Block
protocol) will be pleased that there will no longer be a compile time
option for enabling workarounds for (released broken) Win9x systems.
Instead, Linux will be able to detect what kind of system it is connecting
to and enable bug fixes as needed. This will make Linux a considerably
better option for heterogeneous networks. (This is a SMB client only, the
popular Samba package can be used if server features or access to printers
is desired.)
   
Of special importance to many Linux users is Linux's ability to mount the
shared drives of UNIX operating systems. Linux 2.4 includes for the first
time the ability to access NFS shares which conform to version 3 of the
NFS protocol. NFS version 3 includes many advantages over previous
versions and it has been one of Linux's most often requested features for
the enterprise user.
   
There are still some pieces of support that is currently lacking in Linux
2.4. There is no support for journalizing filesystems, for instance. Due
to the relatively low fsck times and the ease of data recovery
journalizing filesystems support, this is considered by many to be an
entrance requirement to the enterprise. HFS+, the successor to HFS and the
filesystem used on some Macintosh disks, is not yet supported. Also not
supported is the UDF format, the format commonly used on DVD drives. It is
hoped that these and other "missing" features will be completed before 2.4
is ready for release however there will be a code freeze coming soon. 
   
Framebuffers

Another, more complicated variety of block device is the frame-buffer. A
frame-buffer is simply a section of memory that represents (or is) video
memory to such an extent that writing to this memory affects the colors of
the pixels on a screen. This is more complicated than some other block
devices because it supports ioctls to change the palette and other
functions associated to video. (While it might be possible to "format"
this device and mount a filesystem from it, I wouldn't recommend you try.)
   
Linux 2.4 includes a number of new drivers and improvements to old
drivers. Especially important here is Linux's support for many more
"standard" VGA cards and configurations, at least in some mode. (Probably
less than optimally.) Please remember that this feature can be bypassed
and (on i386) is only necessary for people with certain systems which
cannot be supported in any other way. At this time, the XFree project
provides many more drivers to many more video cards than the kernel can
support so it is not necessary to use this feature to get X Windows
support. (SVGAlib and other libraries allow you to do direct video
manipulation on supported hardware, however the use of these libraries
must be done carefully as there are some security concerns.)
   
Character Devices - Keyboards, Mice, Consoles, and Ports

The next kind of device that Linux recognizes are character devices. These
are any devices which can be read from or written to but don't have a
"location" per se and can't be accessed outside of order. This includes
terminals, ports, keyboards, mice, and other things that you would expect.
Linux 2.4 also features improvements in this area.
   
The biggest news on this front is that Linux 2.4 will support for the
first time keyboards and mice attached to the Universal Serial Bus. When
plugged in, these input device will behave just as if they were "normal"
keyboards and mice. Additionally, Linux will now work on more systems,
including broken (or specially embedded) ones where the keyboard is not
pre-initialized by the BIOS. Also, better support is provided for machines
without keyboards in some cases. (Mostly for buggy machines that don't
handle the lack of a keyboard as well as one would like.)
   
As much as it may not appear so, all versions of Linux output to the
screen in character mode. (Linux supports a built-in extended vt100
interface to handle cursor positioning. This is done using a very small
text-mode only frame-buffer device.) In the case of a frame-buffer, Linux
2.2 and later support overlaying the framebuffer driver with a terminal
driver allowing identical (sometimes even better) features as (than) the
built-in text mode.
   
Linux 2.4 does not include many major changes to this subsystem however it
does for the first time support redirecting the console (the primary
display used for Linux kernel messages) to the parallel port for, for
example, a printer. (Earlier versions of Linux already supported
redirecting messages to serial ports.) This functionality will be of
primary interest to some developers and server applications which want to
maintain a hard-copy of kernel and debug messages that Linux uses.
   
Of course, Linux would not go far without excellent support for ports, the
truest form of character device. These can generally be divided between
serial and parallel varieties.
   
Serial support for Linux 2.4 has not changed much and many of the same
limitations from 2.2 still apply. (In particular, setting module options
is generally done with an external utility rather than the standard
parameters passed to modules.) Later versions of Linux 2.2 and all
versions of Linux 2.4 will allow one to share IRQs on PCI serial boards;
previously this was only allowed on ISA cards and on-board serial ports.
Some other pieces of multiport hardware will be better supported under
Linux 2.2. More updates and new drivers are flowing in regularly.
   
In contrast, the parallel port subsystem has undergone some major
overhauls since 2.2. There is now a generic parallel port driver for
abstracted communication with "unknown" types of parallel devices. This
could be used, for example, by programs that want to poll the parallel
port for Plug-and-Play information as we described earlier. It is these
changes that allow us the side-effect of being able to use the parallel
port as a console. Also, Linux 2.4 supports using all the different modes
of modern parallel ports, including writing to the parallel ports using
DMA, if supported in the hardware. This will speed up access to printers
and other parallel devices.
   
Infra-red support has progressed since Linux 2.2 and there have been many
changes in this area, including better network support.
   
In a separate department, there has been some (but little) work since 2.2
on supporting so-called "WinModems" (or "soft modems" or "Linmodems").
These are modems which exist largely in software and whose drivers are
often only provided by the manufacturer for Windows. (Hence the common
name.) While no code has been submitted to Linus for the support of these
beasts, it is possible that we may see some support for them before 3.0.
One major obstacle here is that each and every WinModem is different; it
is unlikely that a driver for one would be applicable to another and the
sheer number of different types of WinModems would make this difficult or
impossible to ever get a decent selection of hardware supported.
Impossible odds have never fazed open source developers however and I for
one will not be surprised when the first driver makes it into the kernel,
someday. Much of the legwork has already been completed.
   
There are some other places where some people feel that Linux 2.4
could improve, of course. With the addition of USB we have the chance
to have multiple keyboards and mice attached to the same bus. Linux
2.4 however does not have internal multi-heading of these devices; you
cannot assign one keyboard and one mouse to one terminal and another
set to a different terminal. Support for this is provided in the GGI
project (a project to provide multi-heading, frame-buffering, and
other features to the Linux kernel), however this project's code has
not yet (and may never be) synched into the mainstream kernel. (It is
however a good place to check if you need this functionality.)
   
Accessibility
  
Linux is not commonly regarded as a "user friendly" operating system.
Therefore, one would be surprised to learn that Linux 2.4 (and some later
versions of Linux 2.2) includes support for its first speech synthesizer
card. These cards will allow Linux users to hear all Linux output,
including messages early in the boot process. Very few operating systems
can boast such complete support for these devices at the kernel level.
(Other patches and utilities are still required to get the full use out if
these cards, however their presence in the kernel is a giant leap in the
right direction for Linux.)
   
Multimedia: Sound, TV, Radio, etc.

On the complicated side of the character device list, we have some of the
"fluffier" devices to be supported by Linux. Linux, in its emerging role
as a desktop platform, tries very hard to support these devices, including
sound cards, TV and radio tuners, and other sound and video output
devices. To be honest, Linux 2.4 does not include as many ground-breaking
changes as Linux 2.2 did in this respect. Linux 2.4 does however include
updates and new drivers for a variety of sound and video cards, including
full duplex support. Linux 2.4 and some later versions of Linux 2.2 also
include code which will allow some sound devices to more easily allocate
memory in required ranges; this should make the configuration and use of
some cards much easier.
   
Networking and Protocols

Even further distant from the simplicity of keyboards and mice, networking
and network hardware is one of the major areas where Linux has always
excelled. These beasts are neither "character" nor "block" but inhabit a
special space free of the need for device nodes. Linux 2.4 will include
many improvements to this layer including new drivers, bug fixes, and new
functionality added on to existing drivers.
   
The Linux model of network sockets is one which is standard across most
UNIX variants. Unfortunately however, the standard does have some
deficiencies but these deficiencies can be corrected without breaking the
standard altogether. Under Linux 2.2 and previous versions, if you have a
number of processes all waiting on an event from a network socket (a web
server, for instance), they will all be woken up when activity if
detected. So, for every web page request received, Linux would wake up a
number of processes which would each try and get at the request. As it
does not make sense for multiple processes to serve the same request, only
one will get to the data; the remainder will notice that it doesn't have
anything to process and fall back asleep. Linux is quite efficient at
making this all happen as quickly as possible, however it is still very
inefficient... but there is a better way. Linux 2.4 includes changes which
implement "wake one" under Linux which will allow us to completely remove
the "stampede effect". In short, "wake one" does exactly as its name
indicates: wakes up only one process in the case of activity. This will
allow applications such as Apache to be even more efficient and make Linux
an even better choice as a web server.
   
Linux 2.4 also includes a completely rewritten networking layer. In fact,
it has been made an unserialized as possible so that it will scale far
better than any previous version of Linux. In addition, it contains many
optimizations to allow it to work with the particular quirks of the
networking stacks in use in many common operating systems, including
Windows. It should also be mentioned at this point that Linux is still the
only operating system completely compatible with the IPv4 specification
(Yes, IPv4) and Linux 2.4 boasts an IPv4 implementation that is much more
scalable than its predecessor. As Linux 2.2 became completely compatible
with the specification, the use of "colon mode" for aliasing was
deprecated. This functionality was completely removed in Linux 2.4 and
may require some advanced users to partially rewrite scripts.
   
Next to the new network layer, the next most important improvement in the
Linux 2.4 network layer is the addition of code to handle the DECNet
protocols. This allows for better interoperation with specialized
Digital/Compaq systems.
   
For the low-end desktop users, PPP is an important part of day to day
life. Linux 2.4 includes some major rewrites and modularization of much of
the code, including a long awaited combination of the PPP layers from the
ISDN layer and the PPP layer used on serial devices, such as modems.
   
--

All in all, I feel that Linux 2.4 will probably be known as the
"desktop" Linux for all its new desktop features. I hope someone
doesn't quote me on that as Linux 2.4 includes many features that are
great for servers and embedded systems. At the heart of the matter,
is there really a difference?

This is the final version. If you haven't commented on it by now and
I missed something that you feel is important, please email me at
jpranevich@linuxtoday.com and maybe I'll put out a patch. :)