|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Sergey Lentsov 2:4615/71.10 14 Mar 2002 18:30:54
To : All
Subject : URL: http://www.lwn.net/2002/0314/kernel.php3
--------------------------------------------------------------------------------
[1][LWN Logo] [2][oasisi.php?s=5&w=468&h=60]
[LWN.net]
Sections:
[3]Main page
[4]Security
Kernel
[5]Distributions
[6]Development
[7]Commerce
[8]Linux in the news
[9]Announcements
[10]Letters
[11]All in one big page
See also: [12]last week's Kernel page.
Kernel development
The current development kernel release is 2.5.6, which was
[13]released on March 8. The final release added little to the
prepatches; the main feature of this release from a user's point of
view remains the inclusion of IBM's JFS journaling filesystem.
The [14]first 2.5.7 prepatch has been released. It includes Rusty
Russell's fast user-space semaphore patch ("futexes"), a thrashup of
the VLAN code, the new wireless driver API, a redesigned video device
implementation, and numerous fixes and updates.
Dave Jones has released no "dj" patches over the last week. He has
presented excuses like moving into a new house as a reason for that.
Guillaume Boissiere's latest [15]2.5 status summary is available.
The current stable kernel release is 2.4.18. The current 2.4.19
prepatch from Marcelo is [16]2.4.19-pre3. Along with the usual array
of fixes and updates it includes the "new" IDE code - in its original
form, not the increasingly reworked version found in the 2.5 kernel.
In fact, the -pre3 version is [17]missing some important fixes that
went into 2.5 early on - it still has the bug that caused 2.5 to
destroy filesystems. There have been no reports of corrupted
filesystems with this prepatch, but it should be approached with some
care anyway.
Alan Cox's latest prepatch is [18]2.4.19-pre2-ac4. There is a long
list of fixes, but no amazing new features.
Alan has also [19]announced the first 2.2.21 release candidate.
Other kernel trees. The day may yet come when the number of available
kernel trees exceeds the number of Linux users...
* Andrea Arcangeli's latest is [20]2.4.19-pre3-aa1. It adds his
latest VM implementation (vm-31), the X86-64 port, User-mode
Linux, and a number of fixes.
* J.A. Magallon has released [21]2.4.19-pre2-jam3 with the latest VM
code, the O(1) scheduler, the IDE patch, and other
performance-oriented fixes.
* Joerg Prante has released [22]2.4.19-pre2-jp7 includes ALSA, the
reverse mapping VM, the O(1) scheduler, the preempt patch, the IDE
patch, XFS, JFS, various crypto patches, and much more.
* [23]2.4.19-pre2-ac4-xfs-shawn10 from Shawn Starr includes XFS, the
reverse mapping VM, Jan Kara's reworked quota system, and more.
* A new entry this week is [24]2.4.18-mcp3-WOLK from Marc-Christian
Petersen, which is inspired by the FOLK patch. It throws in
Win4Lin, the preempt patch, the international crypto patch, the
IDE patch, JFS, XFS, FreeS/WAN, NWFS, lm_sensors, and a great many
other patches.
Linus on BitKeeper. It was already clear, of course, that Linus is not
bothered by the BitKeeper license. For anybody who didn't know that,
however, he [25]stated his views this week:
And I personally refuse to use inferior tools because of ideology.
In fact, I will go as far as saying that making excuses for bad
tools due to ideology is _stupid_, and people who do that think
with their gonads, not their brains.
Most of the developers seem to be at ease with his position. It is
worth pondering, however, on why so many of us insisted on using Linux
systems in the early 90's, when it was still clearly inferior to the
numerous proprietary Unix systems that were available at the time.
Without a certain amount of "gonad thinking," Linux might not have
come so far so quickly.
Meanwhile, there has been a small discussion of what features are
offered by BitKeeper that really make it worthwhile for the kernel
developers. Here's a partial list:
* Much nicer merging of patches. The three-way merge tool
([26]screenshot) is seriously slick. But the ability to carry
merges forward through multiple patch sets is just as important.
Merging of patches can be a painful task; having to only do it
once can be a real relief.
* The ability to check in entire patch sets as a single operation.
* The distributed repository feature is a key to the whole thing.
BitKeeper works well with the kernel development style by allowing
each developer to set up independent trees and facilitating the
movement of patches between those trees.
* Understanding of directories and operations like renaming; CVS
does not handle these well at all.
There are developers out there who are talking about adding these
features to the existing free source management systems. It's a
nontrivial task, however; the first release is likely to be some time
in the future. (Then again, Hans Reiser [27]wants to incorporate
version control into the filesystem, and plans to do so with a future
ReiserFS release. "Version control has to become just another expected
filesystem feature, and one that is so transparent to users that Mom
uses it without fear.")
The hostile takeover of the 2.5 IDE code is now officially complete:
Martin Dalecki's [28]IDE 18 patch changed the MAINTAINERS file to list
him as the person in charge of that subsystem. There were no immediate
complaints, but things heated up a bit when he released [29]IDE 19.
Therein were comments like:
Apply Pavels Macheks patch for suspend support. Whatever some
persons argue that it's not fully implemented, I think that we are
in development series right now. I don't buy the mock-up examples
for problems with either outdated or broken hardware. Micro Drives
are for example expected to be drop in replacements for CF cards in
digital cameras and I would rather expect them to be very tolerant
about the driver in front of them.
Martin has also [30]been heard to say: "Breakage is the price you have
to pay for advancements."
It turns out that some kernel developers are not entirely pleased with
the idea of "breakage" in the IDE code - they like their disks to
work. There is a feeling that it is better to follow the standards
than to expect drives "to be very tolerant about the driver in front
of them." Few people have come out in defense of the existing code,
but some feel that the current approach to "cleaning up" the IDE code
is negligent to the point of carelessness.
The discussion, in fact, involved some of the most unpleasant personal
attacks seen on linux-kernel for some time. It also appears to have
changed little; Martin continues to crank out IDE patches, and Linus
continues to accept them. Perhaps Martin has received a message,
however, that standards compliance and stability are important. When
it comes to disks, people are not willing to pay for their
advancements with any great amount of breakage.
On the future of IDE taskfile commands. The IDE taskfile ioctl (which
allows passing arbitrary low-level commands to IDE peripherals) has
generally been the source of no end of inflammatory discussions in its
own right. Compared to the other IDE threads, however, the current
taskfile discussion seems like a new height of civility and technical
content.
The issue is not whether low-level commands should be allowed - there
is widespread agreement that this capability is occasionally required.
Diagnostic code needs it, if nothing else. But when Andre Hedrick
first implemented the taskfile capability, he included an IDE command
parser to ensure that all commands passed to the drives were legal
according to the standards. There never has been a consensus on
whether this sort of command filtering is appropriate.
Those in favor of filtering point out that the consequences of
executing a malformed IDE command can be severe: loss of data or, in
the worst case, having to throw away a brick that was once a working
drive. Filtering can thus protect against both programming errors and
deliberate attacks. Proponents of filtering also see it as a possible
way of defeating future "digital rights management" schemes which may
depend on new, undocumented IDE commands.
The opposition points out that most drives have some unique,
vendor-specific commands. Unless somebody wants to build (and
maintain) a table of all such commands, any filtering is certain to
block legitimate commands for some users. The protection against
attacks is seen as being weak at best, since a process which is able
to execute taskfile commands can also just go and pound on the I/O
ports directly. And dealing with DRM schemes is probably not going to
be so simple.
For all these reasons, Linus has generally been against IDE command
filtering. He also [31]points out that the IDE layer should not be
performing any such filtering in any case. The IDE layer, after all,
is a driver for the IDE host controller; the commands to be filtered
are, instead, aimed at IDE disks. Linus compares IDE filtering to
having a network adapter driver perform validity testing and filtering
for network protocols.
There are some things that need to be done with low-level commands,
however. At a minimum, the buffers they use must be verified. But it
would also be a very good idea to better sequence their execution with
all of the other IDE commands that may be running at the same time.
So Linus has [32]proposed a new scheme for the handling (and possible
filtering) of low-level IDE commands. These commands would be moved
out of the IDE driver, into a separate loadable module. Paranoid
administrators who do not want those commands executed at all could
simply remove the module from their systems entirely. The rest could
configure a module which did as much (or little) filtering as they
wanted.
This module would not talk directly with the IDE subsystem. Instead,
any low-level commands would be run through the drive's request queue
along with all the other drive operations. This scheme forces
low-level commands to be sequenced along with any other disk activity,
and should help ensure that they are executed in a way that doesn't
interfere with the other things the system is trying to do.
There have been very few complaints about this proposal. It's
implementation would be some work, but there may just be a solution to
the problem of the taskfile commands and filtering in sight.
Going for the fastest kernel compile. Martin Bligh posted [33]an
interesting note this week. He started with the 2.4.18 kernel and a
16-node NUMA system using 700MHz P3 processors. With that system, he
was able to build a kernel in 47 seconds, which would make most of us
reasonably happy. Martin wasn't satisfied with that, though, so he
applied a series of patches to bring that time down:
* Various NUMA memory allocation fixes: 27 seconds.
* The O(1) scheduler from 2.5: 25 seconds.
* A NUMA-oriented scheduler patch: 24 seconds.
* A dcache patch which improves cache behavior: 23 seconds.
Compiling a kernel in 23 seconds isn't bad - it looks like a record.
Records, though, are meant to be broken. So Anton Blanchard [34]rose
to the challenge with a 24-node "logical partition" on a PowerPC64
system running a patched version of 2.5.6. Building a kernel with the
same configuration as Martin's, above, he got the job done in 10.3
seconds. That will be a hard performance to beat, but somebody,
somewhere, is certainly working on it.
Other patches and updates released this week include:
Core kernel code:
* Robert Love has posted [35]a new version of his system call
allowing processes to set their processor affinity.
* A new version of the delayed allocation patch has been [36]posted
by Andrew Morton. He might just be looking for people to try it
out: "Does anyone know what 'CFT' means? It means 'call for
testers'. It doesn't mean 'woo-hoo, it'll be neat when that's
merged <delete>'. It means 'help, help - there's no point in just
one guy testing this'."
* Larry Kessler has [37]released an implementation of POSIX event
logging for the 2.5.6 and 2.4.18 kernels.
* Rik van Riel has [38]released a kernel with the reverse mapping VM
in RPM format.
* Erich Focht has posted [39]a new version of his NUMA scheduler.
Development tools:
* The Linux Test Project [40]ltp-20020307 release is available.
Numerous new tests have been added.
* Keith Owens has [41]released kdb 2.1-2.4.18 for the Sparc64
architecture.
Device drivers
* The [42]seventh test release of the new Tigon3 driver has been
announced by David Miller.
* A new beta Conexant HCF "linmodem" driver has been [43]announced
by Marc Boucher.
Filesystems and related:
* Kevin Corry has [44]announced version 0.9.2 of the Enterprise
Volume Management System.
* A new, vastly reworked disk quota system has been [45]posted by
Jan Kara.
* Steve Best has [46]announced the release of JFS 1.0.16.
* Andreas Gruenbacher has [47]released version 0.8.20 of the access
control list patch.
Miscellaneous:
* Rusty Russell has [48]posted a fast userspace read/write lock
("furwock") implementation based on futexes. He has also posted
[49]an explanation of how futexes work.
Networking:
* This week's release of the Affix BlueTooth stack is [50]version
0_94.
* Alexander Viro has [51]posted an implementation of the "nfsd"
filesystem - a new way of communicating with the NFS server
process to perform tasks like exporting filesystems.
Ports:
* James Bottomley has posted [52]a new version of his port to the
NCR Voyager architecture.
Section Editor: [53]Jonathan Corbet
March 14, 2002
For other kernel news, see:
* [54]Kernel traffic
* [55]Kernel Newsflash
* [56]Kernel Trap
* [57]Linux 2.5.x Porting help
* [58]2.5 Status
Other resources:
* [59]Kernel Source Reference
* [60]L-K mailing list FAQ
* [61]Linux-MM
* [62]Linux Scalability Effort
* [63]Kernel Newbies
* [64]Linux Device Drivers
[65]Next: Distributions
[66]Eklektix, Inc. Linux powered! Copyright Л 2002 [67]Eklektix, Inc.,
all rights reserved
Linux (R) is a registered trademark of Linus Torvalds
References
1. http://lwn.net/
2. http://oasis.lwn.net/oasisc.php?s=5&w=468&h=60
3. http://lwn.net/2002/0314/
4. http://lwn.net/2002/0314/security.php3
5. http://lwn.net/2002/0314/dists.php3
6. http://lwn.net/2002/0314/devel.php3
7. http://lwn.net/2002/0314/commerce.php3
8. http://lwn.net/2002/0314/press.php3
9. http://lwn.net/2002/0314/announce.php3
10. http://lwn.net/2002/0314/letters.php3
11. http://lwn.net/2002/0314/bigpage.php3
12. http://lwn.net/2002/0307/kernel.php3
13. http://lwn.net/2002/0314/a/2.5.6.php3
14. http://lwn.net/2002/0314/a/2.5.7-pre1.php3
15. http://lwn.net/2002/0314/a/2.5-status.php3
16. http://lwn.net/2002/0314/a/2.4.19-pre3.php3
17. http://lwn.net/2002/0314/a/ide-problems.php3
18. http://lwn.net/2002/0314/a/2.4.19-pre2-ac4.php3
19. http://lwn.net/2002/0314/a/2.2.21-rc1.php3
20. http://lwn.net/2002/0314/a/2.4.19-pre3-aa1.php3
21. http://lwn.net/2002/0314/a/2.4.19-pre2-jam3.php3
22. http://lwn.net/2002/0314/a/2.4.19-pre2-jp7.php3
23. http://lwn.net/2002/0314/a/2.4.19-pre2-ac4-xfs-shawn10.php3
24. http://lwn.net/2002/0314/a/2.4.18-mcp3-WOLK.php3
25. http://lwn.net/2002/0314/a/lt-bitkeeper.php3
26. http://www.bitkeeper.com/newmerge.gif
27. http://lwn.net/2002/0314/a/reiser-vc.php3
28. http://lwn.net/2002/0314/a/ide-18.php3
29. http://lwn.net/2002/0314/a/ide-19.php3
30. http://lwn.net/2002/0314/a/breakage.php3
31. http://lwn.net/2002/0314/a/lt-filtering.php3
32. http://lwn.net/2002/0314/a/lt-filter-module.php3
33. http://lwn.net/2002/0314/a/23-second-compile.php3
34. http://lwn.net/2002/0314/a/10-second-compile.php3
35. http://lwn.net/2002/0314/a/affinity.php3
36. http://lwn.net/2002/0314/a/delayed-allocation.php3
37. http://lwn.net/2002/0314/a/evlog.php3
38. http://lwn.net/2002/0314/a/rmap-rpm.php3
39. http://lwn.net/2002/0314/a/numa-scheduler.php3
40. http://lwn.net/2002/0314/a/ltp.php3
41. http://lwn.net/2002/0314/a/kdb-sparc64.php3
42. http://lwn.net/2002/0314/a/tigon.php3
43. http://lwn.net/2002/0314/a/hcf.php3
44. http://lwn.net/2002/0314/a/evms.php3
45. http://lwn.net/2002/0314/a/quota.php3
46. http://lwn.net/2002/0314/a/jfs.php3
47. http://lwn.net/2002/0314/a/acl.php3
48. http://lwn.net/2002/0314/a/furwocks.php3
49. http://lwn.net/2002/0314/a/futex-explanation.php3
50. http://lwn.net/2002/0314/a/affix.php3
51. http://lwn.net/2002/0314/a/nfsd.php3
52. http://lwn.net/2002/0314/a/voyager.php3
53. mailto:lwn@lwn.net
54. http://kt.zork.net/
55. http://www.atnf.csiro.au/~rgooch/linux/docs/kernel-newsflash.html
56. http://www.kerneltrap.com/
57. http://www.osdl.org/archive/rddunlap/linux-port-25x.html
58. http://kernelnewbies.org/status/
59. http://lksr.org/
60. http://www.tux.org/lkml/
61. http://www.linux.eu.org/Linux-MM/
62. http://lse.sourceforge.net/
63. http://www.kernelnewbies.org/
64. http://www.xml.com/ldd/chapter/book/index.html
65. http://lwn.net/2002/0314/dists.php3
66. http://www.eklektix.com/
67. http://www.eklektix.com/
--- ifmail v.2.14.os7-aks1
* Origin: Unknown (2:4615/71.10@fidonet)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
| Тема: |
Автор: |
Дата: |
|
URL: http://www.lwn.net/2002/0314/kernel.php3 |
Sergey Lentsov |
14 Mar 2002 18:30:54 |
|
|
