|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Sergey Lentsov 2:4615/71.10 08 Jul 2001 23:38:05
To : All
Subject : URL: http://www.lwn.net/2001/0704/kernel.php3
--------------------------------------------------------------------------------
[1][LWN Logo]
[2]Click Here
[LWN.net]
Sections:
[3]Main page
[4]Security
Kernel
[5]Distributions
[6]On the Desktop
[7]Development
[8]Commerce
[9]Linux in the news
[10]Announcements
[11]Linux History
[12]Letters
[13]All in one big page
See also: [14]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 [15]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 [16]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 [17]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 [18]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 [19]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
[20]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 [21]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: [22]Steve Best's overview of JFS on the IBM developerWorks
site).
Concerns about ACPI. The [23]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 [24]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:
* 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 [25]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 [26]a document describing how the new
PCI power management interface works.
* The Linux Test Project has [27]announced a new release which
includes quite a few new tests.
* Jeff Merkey has [28]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 [29]a patch implementing 64-bit block
sizes. Included is a demonstration of a 7TB filesystem running
with this code.
* Daniel Phillips has [30]a new early flush patch (see [31]last
week's kernel page) which adds continuous bandwidth estimation to
the mix.
* [32]A new hotplug CPU patch has been posted by Rusty Russell.
* [33]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: [34]Jonathan Corbet
July 4, 2001
For other kernel news, see:
* [35]Kernel traffic
* [36]Kernel Newsflash
* [37]Kernel Trap
Other resources:
* [38]Kernel Source Reference
* [39]L-K mailing list FAQ
* [40]Linux-MM
* [41]Linux Scalability Project
* [42]Kernel Newbies
[43]Next: Distributions
[44]Eklektix, Inc. Linux powered! Copyright Л 2001 [45]Eklektix, Inc.,
all rights reserved
Linux (R) is a registered trademark of Linus Torvalds
References
1. http://lwn.net/
2. http://ads.tucows.com/click.ng/pageid=001-012-132-000-000-003-000-000-012
3. http://lwn.net/2001/0704/
4. http://lwn.net/2001/0704/security.php3
5. http://lwn.net/2001/0704/dists.php3
6. http://lwn.net/2001/0704/desktop.php3
7. http://lwn.net/2001/0704/devel.php3
8. http://lwn.net/2001/0704/commerce.php3
9. http://lwn.net/2001/0704/press.php3
10. http://lwn.net/2001/0704/announce.php3
11. http://lwn.net/2001/0704/history.php3
12. http://lwn.net/2001/0704/letters.php3
13. http://lwn.net/2001/0704/bigpage.php3
14. http://lwn.net/2001/0628/kernel.php3
15. http://lwn.net/2001/0704/a/2.4.6.php3
16. http://lwn.net/2001/0704/a/2.4.5ac24.php3
17. http://lwn.net/2001/0704/a/jffs-patch.php3
18. http://lwn.net/2001/0704/a/lt-jffs.php3
19. http://lwn.net/2001/0704/a/lt-disallow.php3
20. http://lwn.net/2001/0704/a/lt-messages.php3
21. http://lwn.net/2001/0704/a/jfs-1.0.php3
22. http://www-106.ibm.com/developerworks/library/jfs.html
23. http://www.teleport.com/~acpi/
24. http://www.teleport.com/~acpi/spec.htm
25. http://lwn.net/2001/0704/a/ac-acpi.php3
26. http://lwn.net/2001/0704/a/pcipm-doc.php3
27. http://lwn.net/2001/0704/a/ltp.php3
28. http://lwn.net/2001/0704/a/nwfs.php3
29. http://lwn.net/2001/0704/a/64bit-blocksize.php3
30. http://lwn.net/2001/0704/a/early-flush.php3
31. http://lwn.net/2001/0628/kernel.php3
32. http://lwn.net/2001/0704/a/hotplug-cpu.php3
33. http://lwn.net/2001/0704/a/alsa.php3
34. mailto:lwn@lwn.net
35. http://kt.zork.net/
36. http://www.atnf.csiro.au/~rgooch/linux/docs/kernel-newsflash.html
37. http://www.kerneltrap.com/
38. http://lksr.org/
39. http://www.tux.org/lkml/
40. http://www.linux.eu.org/Linux-MM/
41. http://www.citi.umich.edu/projects/linux-scalability/
42. http://www.kernelnewbies.org/
43. http://lwn.net/2001/0704/dists.php3
44. http://www.eklektix.com/
45. http://www.eklektix.com/
--- ifmail v.2.14.os7-aks1
* Origin: Unknown (2:4615/71.10@fidonet)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
| Тема: |
Автор: |
Дата: |
|
URL: http://www.lwn.net/2001/0704/kernel.php3 |
Sergey Lentsov |
08 Jul 2001 23:38:05 |
|
|
