![[LWN Logo]](http://old.lwn.net/images/lcorner.png)
![[LWN.net]](http://old.lwn.net/images/kernel.png)
|
|
|
 Sections: Main page Security Kernel Distributions On the Desktop Development Commerce Linux in the news Announcements Linux History Letters All in one big page See also: last week's Kernel page. |
Kernel developmentThe 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. 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:
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) {
Name(REGC,Ones)
Method(_REG,2) {
If (Lequal(Arg0, 3)) {
Store(Arg1, REGC)
}
}
Method(ECAV,0) {
If (Lequal(REGC,Ones)) {
If (LgreaterEqual(_REV,2)) {
Return(One)
}
Else {
Return(Zero)
}
}
Return(REGC)
}
}
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:
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:
Section Editor: Jonathan Corbet |
July 4, 2001
| ||
Copyright © 2001
Eklektix, Inc., all rights reserved
Next: Distributions