[LWN Logo]

 Main page
 On the Desktop
 Linux in the news
 Linux History
All in one big page

See also: last week's Kernel page.

Kernel development

The current kernel release is 2.4.6, which came out just as this page was going to "press." The changelog shows no additions after 2.4.6pre9, which appears to have been stable for most, if not all users.

Alan Cox, meanwhile, is up to 2.4.5ac24.

Now that 2.4.6 is out, 2.5.0 release in the near future would not be all that surprising.

Quieting the kernel. It all started with a small patch to the journaling flash filesystem (JFFS) code which caused the following to be printed at system boot:

    Portions (C) 2000, 2001 Red Hat, Inc.
Also included was a rather pointed comment directed at a competing company which, it is alleged, had taken liberties with the code in the past. Linus, as is occasionally his wont, decided that it was time to draw a line; he turned down the patch saying that he doesn't like printed copyright messages.

You're allowed to remove offensive printk's, that's not a copyright notice in Linux, that's just a big ugly bother. The copyright notice is that big comment at the top of the file.

Later he took the argument further, saying that these sorts of messages should be removed from the kernel:

So let's simply disallow versions, author information, and "good status" messages, ok? For stuff that is useful for debugging (but that the driver doesn't _know_ is needed), use KERN_DEBUG, so that it doesn't actually end up printed on the screen normally.

Authors willing to start sending me patches?

At that point the developers got into a full discussion on the utility of these sorts of messages. Those who want them removed, Linus in particular, cite the following arguments:

  • There is no useful information content in these messages; instead, they are a distraction when something goes wrong and real information is needed.

  • Excessive boot-time messages inspire distributors to turn off messages entirely, including ones that really are needed to debug problems.

  • Large numbers of printk() calls bloat the kernel to no useful end.
Quite a few people want to retain the messages however, even though they do acknowledge that they sometimes go overboard. Their reasoning is:
  • Routine boot-time messages are a useful debugging tool. Developers who are trying to track down problems routinely ask for a copy of the output from dmesg, or, for more severe problems, "the last thing it prints before it dies."

  • Having one's name in a boot-time message is a form of advertising that is an important compensation for free software development work.

  • Some argue that a printed message is a legal copyright notice that can not be removed without infringing that copyright.

Just to show that things don't always go Linus's way: he actually backed down, mostly in the face of the debugging argument. So the messages probably will not go away entirely, but they may well become harder to see. The most likely outcome is that driver success messages will be dropped to the KERN_DEBUG logging level, meaning that they will not normally be visible on the console or in the log files. (There is also talk of a separate logging level for these messages, but that seems unnecessary). When the messages are needed, they can be recovered with dmesg, or, for boot failures, by booting with the "debug" option.

JFS 1.0 released. IBM has announced the 1.0 release of its Journaled File System (JFS). JFS provides the obligatory journaling capability, of course; it also includes a number of scalability features. The extent-based allocation scheme is set up for the efficient handling of large files, and the data structures are "designed to scale beyond practical limit."

Another important feature of JFS is that it requires no changes to the rest of the kernel to install. In this regard, it differs from SGI's XFS, which requires patches to the mainline kernel code. As a result, JFS stands a better chance of being integrated into the 2.4 kernel series than XFS. In the 2.5 series, however, all journaling filesystems are likely to see large changes as the result of memory management changes and the possible implementation of a more general journaling layer.

(See also: Steve Best's overview of JFS on the IBM developerWorks site).

Concerns about ACPI. The Advanced Configuration and Power Interface is the industry's current answer to power management. It is supposed to fix all of the problems with the older APM specification, and provide a great many new features as well. And, in fact, ACPI does promise some nice things. Kernel hackers have always been a bit concerned about ACPI, however, and the level of that concern seems to be rising as the implementation (led by Intel's Andy Grover) increases in functionality.

The concern arises from the complexity of both the ACPI specification and its implementation. There is no doubt that the specification is intense - it is available from the ACPI web site as a 450-page PDF file. The real problem, however, is not the size of the specification itself, but in the way it expects to handle device control.

The ACPI specification defines a language called AML ("ACPI Machine Language"), and an (allegedly) human-readable version called ASL ("ACPI Source Language"). An example from the specification:

Device(EC0) {
    Method(_REG,2) {
        If (Lequal(Arg0, 3)) {
            Store(Arg1, REGC)
    Method(ECAV,0) {
        If (Lequal(REGC,Ones)) {
            If (LgreaterEqual(_REV,2)) {
            Else {

Think of it as a sort of verbose C++ subset with lots of capital letters and no semicolons and that's probably all you really need to know.

BIOS writers are supposed to provide AML code (with the motherboard BIOS or the device itself) which helps each device implement parts of the ACPI specification. Systems implementing ACPI are required to run this code in a privileged mode when required. In other words, to implement ACPI, the Linux kernel must:

  • Run arbitrary, binary-only code from outsiders...
  • ...which implements a huge, complex specification...
  • ...in kernel mode...
  • ...with a bulky interpreter (built into the kernel)...
  • ...hoping that there are no bugs or misfeatures in this code...
  • ...even though BIOS code has been the source of endless headaches for years.
Once you look at it that way, it's not too surprising that people are wondering about the whole thing. As Alan Cox put it:

The fact that it takes more code to parse and interpret ACPI than it does to route traffic on the internet backbones should be a hint something is badly wrong either in ACPI the spec, ACPI the implementation or both

Beyond standard-variety bugs, ACPI code could be a point of entry for surveillance software, "content management" code, and no end of other, malign functions. And it all runs in kernel mode with full access to the system. People don't trust it, and with good reason.

Given all that, one could find it tempting to do without ACPI altogether, and that is what most Linux systems do now. Systems are starting to appear, however, which do not implement the old APM standard, meaning that ACPI must be used for power management tasks. And power management is important; anybody running a large server farm in California would certainly be pleased with better control over power consumption.

More importantly, however, ACPI is also becoming the means for hardware discovery and configuration in general. There will likely come a time, before too long, when an understanding of ACPI will be necessary simply to get a system up and running, even if power management is of no concern. Itanium systems, already, can not run without ACPI. Ignoring ACPI is not an option.

All of this has led some hackers to propose a new approach to ACPI. Instead of implementing the whole specification, interpreter and all, why not put together a minimal subsystem which extracts the needed information from the ACPI tables and ignores the rest? There would be some work involved in this approach; there would certainly be AML control routines which would have to be disassembled and reimplemented. But the result could be a simpler, smaller system that does not need to run external, binary code in order to function.

Of course, the ACPI team, which has put years of effort into the current implementation, sees things a little differently. To them, the full ACPI interpreter is the proper way to deal with changes in the hardware industry, and the concerns being raised are overblown. ACPI detractors should, they say, at least demonstrate some real problems before throwing away that much work.

It may take years to resolve how Linux will deal with ACPI in any definitive way. The possibility of a dual implementation, where both the minimal and the complete ACPI subsystems are available, is real.

Other patches and updates released this week include:

  • Patrick Mochel has posted a document describing how the new PCI power management interface works.

  • The Linux Test Project has announced a new release which includes quite a few new tests.

  • Jeff Merkey has asked Alan Cox to take over the Netware filesystem code. In a very Merkey-like message, he describes the dissolution of the Timpanogas Research Group and the threats he feels he is facing.

  • Ben LaHaise has released a patch implementing 64-bit block sizes. Included is a demonstration of a 7TB filesystem running with this code.

  • Daniel Phillips has a new early flush patch (see last week's kernel page) which adds continuous bandwidth estimation to the mix.

  • A new hotplug CPU patch has been posted by Rusty Russell.

  • ALSA 0.9.0beta5 is out. This release includes a fair amount of new functionality. The final 0.9.0 release will happen sometime in July "if nothing happens."

Section Editor: Jonathan Corbet

July 4, 2001

For other kernel news, see:

Other resources:


Next: Distributions

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