[LWN Logo]
[LWN.net]

Sections:
 Main page
 Security
 Kernel
 Distributions
 Development
 Commerce
 Linux in the news
 Announcements
 Back page
All in one big page

See also: last week's Kernel page.

Kernel development


The current development kernel release is 2.3.31. This kernel was released without announcement, as is usual these days. This patch (1.2 MB) includes a lot of joystick driver work, an AGPGART driver (experimental), 3dfx support in the direct rendering manager, an Aironet 4500 network adaptor driver, and a major thrashup of the USB SCSI driver.

The current stable kernel release remains 2.2.13. The series of 2.2.14 prepatches continues, with 2.2.14pre12being the current release candidate, if all goes well.

Initial support for NUMA systems was quietly slipped into 2.3.30. NUMA stands for "non-uniform memory access"; a NUMA system is a multiprocessor system where, for each processor, the speed of memory access varies depending on the "distance" between the memory and the processor. Using NUMA, the usual performance bottleneck between the memory and the processors can be eased somewhat by providing a special path for each processor to a portion of the installed memory. As a result, NUMA systems more easily scale to larger numbers of processors.

NUMA systems look much like regular SMP systems, in that all memory is accessible by all processors. However, a system which does not take the NUMA speed differential into account will perform poorly. A NUMA-aware operating system will seek to maximize the locality of its memory references, so that it is running out of the fastest memory as much of the time as possible.

Linux has had part of this problem solved for some time: it already tries to avoid moving processes between processors. Even on uniform memory systems, each processor has its own memory cache that gets wasted when a process moves somewhere else.

On NUMA systems, however, each processor really needs to make a point of using its fast memory. And that is what the new code in 2.3.30 does. This code was written by Kanoj Sarcar, who has been doing quite a bit of kernel hacking at SGI. Kanoj's new NUMA code splits memory into regions associated with each processor. When a processor allocates new memory, it tries to do so from its fast pool if possible; otherwise it has to look farther afield. Currently non-local memory is allocated from other processors in a round-robin fashion; eventually that will be changed to a distance-sensitive search.

Much more can be done to improve performance on NUMA systems. For example, kernel code (and shared libraries too) can be replicated across processors so that each runs out of its fast memory. Trying to keep related processes (i.e. those which are sharing memory regions) together on the same processor can also be helpful. But one has to start by getting the underlying system in order; Kanoj Sarcar's work is a good step in that direction.

Should the kernel provide transparent, portable support for binary modules? That was the topic of this week's big battle in linux-kernel. The battle, for all its ferocity, remained somewhat one-sided, however...

In one corner, there is Kendall Bennett of SciTech Software, who started things off with a posting entitled Linux headed for disaster?. Therein he claims that Linux should make it possible to build binary modules which can be loaded into any version of the kernel. His claim is that the variety of hardware supported by Linux would be much wider if binary modules were supported in this manner. Without the need to continually port drivers to new versions, hardware vendors would be much more likely to provide drivers for Linux.

It is true that the problems with driver compatibility can be somewhat annoying. Even for a given kernel release and underlying system architecture, there are a number of variable which affect module compatibility, including:

  • Whether the kernel is built for SMP systems or not,

  • Whether large memory support is being used,

  • Which version of the compiler was used,

  • Whether module versioning is enabled,
and other factors as well. To support all configurations, a separate binary module must be compiled for each combination of the above factors - as well as for each supported kernel version. The current state of affairs does not make life easy for those who would provide binary-only modules.

The battle is one-sided because there is very little sympathy among kernel developers for those who wish to distribute binary-only modules. Indeed, they seem to relish the idea of making that task harder. And there are, in fact, good reasons for not trying to support binary modules across versions and configuration options:

  • Providing a "compatibility" layer would bloat the kernel with legacy cruft, make things buggier, and generally slow down the system for everybody.

  • Kernel developers work hard to maintain compatibility at the application level. Within the kernel, however, they strongly defend their right to break things in the name of improving things. Take away that right, and kernel development would slow down considerably - and legacy cruft would start to build up.

  • When a system that has binary-only modules loaded crashes, it can be very hard to track down (much less fix) the problem. The crash could be caused by the binary driver itself, or it could be a legitimate kernel bug - but there is often no way to tell.

  • The best way to provide forward compatibility - to know that a driver will work for future versions of the kernel - is to have the source available. If there is source, and people care about the driver, somebody will make it work with new kernel versions. Users of binary-only modules are dependent on the distributor.

Thus, people may complain - especially those who would like to make a living off distributing proprietary modules. But the situation is highly unlikely to change.

As an example of the sorts of problems that can arise with binary modules, look no farther than Lucent's release of a PCI modem driver, which was covered last week. This driver was built for Red Hat 6.1 systems, but even Red Hat users have been complaining about troubles making it work. Since no source is available, the problems can not be fixed, and the driver can not be built for any other distribution. According to this note, this situation is unlikely to change anytime soon. Those wanting to give this driver a try may want to grab the RPM versionput up by Definite Software.

Meanwhile, for those looking for a free Lucent PCI modem driver, LTModem 0.9.3 has been announced.

The ALSA Professional Team has announced its existence. ALSA, of course, is the "Advanced Linux Sound Architecture," the next generation of sound drivers for Linux. This new team consists of two developers (Jaroslav Kysela and Abramo Bagnara) who are being funded by SuSE to work full time on ALSA and bring it to some sort of initial completion within a couple of months.

The rumors of the QNX filesystem's death were premature. After having seen the discussion of the maintenance (or lack thereof) of the QNX filesystem last week, an eager kernel hacker (who wishes to remain unnamed for the moment) has stepped up and taken over the maintenance responsibility. QNX lives on...

Other patches and updates released this week include:

  • Gabriel Paubert has announced initial support for VME busses on Intel and PPC systems.

  • kdb v0.6 (a kernel debugger) was released by Scott Lurndal.

  • Jeff Garzik put out a new version of his VIA 82Cxxx audio driver.

  • H.J. Lu released nfs-utils 0.1.4.

  • Devfs v145 was released by Richard Gooch.

Section Editor: Jon Corbet


December 9, 1999

For other kernel news, see:

 

Next: Distributions

 
Eklektix, Inc. Linux powered! Copyright © 1999 Eklektix, Inc., all rights reserved
Linux ® is a registered trademark of Linus Torvalds