|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Sergey Lentsov 2:4615/71.10 03 Jan 2002 18:20:50
To : All
Subject : URL: http://www.lwn.net/2002/0103/kernel.php3
--------------------------------------------------------------------------------
[1][LWN Logo]
[2]Click Here
[LWN.net]
Sections:
[3]Main page
[4]Security
Kernel
[5]Distributions
[6]Development
[7]Commerce
[8]Linux in the news
[9]Announcements
[10]Linux History
[11]Letters
[12]All in one big page
See also: [13]last week's Kernel page.
Kernel development
The current development kernel release is 2.5.1. Linus's 2.5.2
prepatch is up to [14]2.5.2-pre6. This prepatch contains more block
I/O work, of course, though that effort seems to be winding down - for
now. So this prepatch includes a number of other things, including a
merge of many of the fixes from the "dj" patch series, Al Viro's
namespace patch (described in the [15]March 1, 2001 LWN kernel page),
some scheduler work from Davide Libenzi, a USB update that includes
beginning support for USB 2.0, and a number of other things.
One of those "other things" is [16]a 'new and anal' kdev_t type.
kdev_t, the internal kernel representation for device numbers, has
traditionally just been the user-space dev_t in disguise. It is now
defined as a structure as a way of finding all kernel code which
treats kdev_t as a simple number. Even proper code needs editing,
however, since the macros which manipulate kdev_t have changed. As of
-pre6, there is a lot of code which still needs work and which, thus,
does not compile. The -pre6 prepatch is not for people who are not
interested in tracking down these sorts of problems.
The current stable kernel release is 2.4.17, [17]released on
December 21. There was some grumbling that the final 2.4.17 patch
included a couple of new fixes; Marcelo's policy seems to be that
obvious, simple bug fixes can go in even after the last release
candidate.
The [18]first 2.4.18 prepatch came out on December 26; it is a large
patch with a number of architecture updates.
Other prepatches: Dave Jones's current prepatch is at [19]2.5.1-dj10.
It tracks the Linus prepatches through 2.5.2-pre5, and, thus, does not
yet contain the kdev_t work.
Michael Cohen has concluded that the world still needs a 2.4-based
development tree. So, he has released [20]2.4.17-mjc1 to fill that
need. It starts with 2.4.17, of course, but then adds Rik van Riel's
reverse mapping patch, the preemptible kernel patch, software suspend,
Andre Hedrick's IDE work, and more. Despite all that, Michael claims
"I'll try to keep this as close to the 2.4.x line as possible."
2.2 users may be interested in [21]2.2.21-pre2 from Alan Cox.
Scheduler tweaks. The debate on what changes should be made to the
scheduler in 2.5 has not yet really happened. Even so, Linus has
started merging in tweaks to the existing algorithm, in the form of
Davide Libenzi's [22]Time Slice Split Scheduler patch. This patch
changes the way the scheduler handles the "dynamic priority" of
processes; the result, hopefully, is fairer scheduling with lower
overhead.
The Linux scheduler has traditionally handled dynamic priority via a
task structure field called counter; the number stored in counter is,
essentially, the number of clock ticks left in the process's time
slice. By using this count as a priority adjustment, the kernel tries
to divide the processor relatively equally among processes that need
it; a process which has not managed to use up much of its time slice
will be selected over another which has exhausted most of its time.
The new scheduler separates dynamic priority from time slice
accounting by replacing counter with two new task structure fields:
dyn_prio and time_slice. This change simplifies the time slice
accounting in the kernel, and makes it easy to adjust the dynamic
priority for other reasons. For example, a small priority boost can be
given to a process which has just completed an I/O operation without
increasing its time slice.
The new code has been steadily tweaked since its inclusion in the
prepatch, mostly through adjustments to the time slice and dynamic
priority settings. There have been few complaints, but also few posted
benchmark results. And this patch does little to address the
difficulties encountered by the current scheduler on SMP systems. Work
with the scheduling algorithm is likely to continue for some time.
The kernel development process has been discussed from many angles
over the last couple of weeks. Perhaps, at the end of a sometimes
difficult year, developers need to ponder on how to make things
better. Here's a few things that have come up:
* Where is aio? Ben LaHaise first submitted his asynchronous I/O
patches early last year. The AIO code enables user processes to
queue up I/O operations directly from their buffers (i.e. without
being copied through the kernel) without having to wait for their
completion. AIO is a feature that Oracle has wanted for some time,
as have other authors of high-performance applications.
Discussion of the AIO patch on the kernel mailing list has been
light, despite the fact that this patch makes deep and significant
changes to how things have been done. Ben feels that part of the
problem, at least, is the fact that these patches - or at least
the part that reserves the AIO system calls - has not been merged
into the mainline kernel. So there is no easy and stable platform
for people to play with.
Linus likes the AIO patch, but is not ready to merge it, or
reserve system calls, until it has been more thoroughly discussed
on the kernel mailing list. The result is a sort of "chicken and
egg" standoff where AIO never really seems to move forward.
One possible solution is [23]this patch from Keith Owens, which
makes it easy for kernel patches to use temporary system call
numbers. System calls are registered at system boot (or module
load) time, and they are exported to user space via a /proc
interface. Properly written applications will be able to find the
system calls they need, and they will continue to run properly
even if those numbers change.
* Units in the kernel. When somebody talks about "kilobytes," what
unit are they really using? "Kilo" traditionally means 10^3
(1000), but, in the computing world, it often means 2^10 (1024)
instead. A similar ambiguity exists for the "mega" prefix (10^6 or
2^20) as well. For the most part, people have lived with this
fuzziness without trouble, but there are always those who feel
that it's better to be exact.
There is, in fact, [24]a standard for the description of binary
multiples. According to this standard, a "kilobyte" of memory is
really a "kibibyte", and should be written "KiB". The standard
also defines "mebi," "gibi," and so on. These definitions have
been around since 1998, but their use has been minimal.
When these units started showing up in the kernel's Configure.help
file, some [25]complaints started rolling in. Not everybody likes
these units, to say the least. Eric Raymond, current keeper of
Configure.help, has [26]stated that he will continue to follow the
published standards unless there is a clear consensus to the
contrary. Clear consensus can be a scarce thing on the kernel
mailing list, however, and no such consensus seems to have emerged
on this issue.
* Patch management. Low-level grumbling about patches being dropped
by Linus (and others) has been a constant linux-kernel feature for
a while. Patches sent to Linus often seem to just fall into the
void; they are not applied, and no response comes back. Developers
will often find that a patch finally goes in after having been
submitted, without response, several times. It can be demoralizing
for a hacker to be continually updating a patch to track the
current kernel releases with no feedback as to whether it will
eventually be included or not.
One idea that occasionally comes up is the use of a patch
management system. That was actually tried once, some years ago,
but Linus has since stopped using the system. Among other things,
[27]says Linus, there is not much use in actually tracking patches
over time. If they are not incorporated into the kernel, they go
stale in a hurry and can no longer easily be applied. Linus, would
rather that the job of merging patches with other developments
stay with the originator of the patch. It also seems that Linus
would rather work with people who will be persistent enough to
maintain their patches until they are included, on the theory that
these people will continue to maintain the code after inclusion.
The patch management issue, in particular, is likely to help drive the
continuing success of the alternative kernel trees. Increasingly, one
or more of these trees is likely to become a necessary staging area
where patches can be tried out before finding their way into the
mainline kernel. In fact, [28]Linus says that the multiple trees are
one of the strengths of the kernel development process for a number of
reasons, one of which is patch management.
The Linux kernel is almost alone in its use of multiple trees as part
of the development process. Many projects have stable and development
branches, but few have multiple trees on either the stable or
development side. It will be interesting to see if the multiple-tree
idea proves useful enough to spread more widely in the free software
development world.
The new kernel build implementation remains a topic of interest. Eric
Raymond has sent out a [29]the state of the new config and build
system message stating that everything was ready to go whenever Linus
is. Keith Owens, meanwhile, has released [30]kbuild 1.12 for the 2.5
kernel. There remains one little problem, however: the new kbuild
takes about twice as long to execute a full kernel build. Not
surprisingly, the kernel developers are not entirely enthusiastic
about this state of affairs. They wait on kernel builds every day and
have little taste for a change that makes things far slower.
Keith's [31]response to the complaints is essentially this: the new
kbuild fixes a number of problems, especially with regard to handling
of dependencies, that exist in the current kbuild system. Correctness
comes first, with performance to follow. Keith believes that he can
fix the performance problems, fairly quickly, but only after the
kbuild code has been integrated into the kernel. Until then, he is
busy enough just managing the patch and keeping it current with kernel
releases.
Linus, you have a choice between a known broken build system and a
clean and reliable system, which is slightly slower in mark 1.
Please add kbuild 2.5 to the kernel, then I will have time to
rewrite the core programs for speed. Mark 2 of the core code will
be significantly faster.
There has been no word from Linus. In the view of many kernel
developers, however, who have not generally had trouble with the
existing build system, the new kbuild should not be merged until the
performance problems have been dealt with. Keith has already made some
steps in that direction with [32]a new design for the management of
the data used by the kbuild process.
Other patches and updates released this week include:
* Rusty Russell has posted [33]a new /proc/sys implementation which
creates a completely new filesystem for single-value items.
* Pavel Machek has posted [34]a new software suspend patch for
2.5.1.
* Jean Tourrilhes continues work on the new wireless driver API; the
[35]latest patch adds for support for wireless events.
* [36]kdb 2.0 for 2.4.17 was released by Keith Owens.
* Dmitri Kassatkine has [37]announced version 0.9pre7 of the affix
BlueTooth stack. [38][hviz graph]
* Jeff Dike has [39]released version 0.54-2.4.7 of the User-mode
Linux port. Jeff also [40]states that he has sent a UML port off
to Linus for inclusion in 2.5.
* Arnaldo Carvalho de Melo has [41]posted a tool which plots the
dependencies between Linux kernel include files. An example of its
output may be seen on the right.
* Christoph Hellwig has [42]released a DRM 4.0 patch for the 2.4.17
kernel.
* A new [43]high-resolution timers patch was announced by George
Anzinger.
* The [44]Linux Kernel Source Finder is a new web page, maintained
by David Alan Gilbert, containing pointers to the definitive
archives for non-x86 Linux kernel sources.
* [45]Kernel Traffic #148 (December 31) is available.
* James Bottomley has [46]posted a patch adding support for the NCR
voyager architecture.
* Momchil Velikov has posted [47]a patch improving the performance
of the kernel page cache in a number of ways.
* Rik van Riel has posted [48]a 2.4.17 VM implementation with
reverse mapping support. The announcement describes what is in the
patch, but people who want to actually run the code should use
[49]version 10a instead.
* A [50]BeOS filesystem implementation for Linux is available from
Will Dyson.
* Andrew Cannon has [51]a filesystem driver for the Radisys RBF
filesystem.
* [52]devfs 199.6 (for 2.4.17) and [53]devfs 205 (2.5.1) were
released by Richard Gooch.
* Zygo Blaxell has [54]posted a CryptoAPI patch for 2.4.17.
* CML2 1.9.20 has been [55]released by Eric Raymond.
* The third stable release of USAGI (the "UniverSAl playGround for
Ipv6") was [56]announced by Kanda Mitsuru.
Section Editor: [57]Jonathan Corbet
January 3, 2002
For other kernel news, see:
* [58]Kernel traffic
* [59]Kernel Newsflash
* [60]Kernel Trap
* [61]Linux 2.5.x Porting help
Other resources:
* [62]Kernel Source Reference
* [63]L-K mailing list FAQ
* [64]Linux-MM
* [65]Linux Scalability Effort
* [66]Kernel Newbies
* [67]Linux Device Drivers
[68]Next: Distributions
[69]Eklektix, Inc. Linux powered! Copyright Л 2002 [70]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/2002/0103/
4. http://lwn.net/2002/0103/security.php3
5. http://lwn.net/2002/0103/dists.php3
6. http://lwn.net/2002/0103/devel.php3
7. http://lwn.net/2002/0103/commerce.php3
8. http://lwn.net/2002/0103/press.php3
9. http://lwn.net/2002/0103/announce.php3
10. http://lwn.net/2002/0103/history.php3
11. http://lwn.net/2002/0103/letters.php3
12. http://lwn.net/2002/0103/bigpage.php3
13. http://lwn.net/2001/1220/kernel.php3
14. http://lwn.net/2002/0103/a/2.5.2-pre6.php3
15. http://lwn.net/2001/0301/kernel.php3
16. http://lwn.net/2002/0103/a/kdev_t.php3
17. http://lwn.net/2002/0103/a/2.4.17.php3
18. http://lwn.net/2002/0103/a/2.4.18-pre1.php3
19. http://lwn.net/2002/0103/a/2.5.1-dj10.php3
20. http://lwn.net/2002/0103/a/2.4.17-mjc1.php3
21. http://lwn.net/2002/0103/a/2.2.21-pre2.php3
22. http://lwn.net/2002/0103/a/tsss.php3
23. http://lwn.net/2002/0103/a/temp-syscall.php3
24. http://physics.nist.gov/cuu/Units/binary.html
25. http://lwn.net/2002/0103/a/kibi.php3
26. http://lwn.net/2002/0103/a/esr-kibi.php3
27. http://lwn.net/2002/0103/a/lt-patch-mgmt.php3
28. http://lwn.net/2002/0103/a/lt-trees.php3
29. http://lwn.net/2002/0103/a/state-of-kbuild.php3
30. http://lwn.net/2002/0103/a/kbuild.php3
31. http://lwn.net/2002/0103/a/ko-kbuild.php3
32. http://lwn.net/2002/0103/a/kbuild-db.php3
33. http://lwn.net/2002/0103/a/proc.php3
34. http://lwn.net/2002/0103/a/swsusp.php3
35. http://lwn.net/2002/0103/a/wireless.php3
36. http://lwn.net/2002/0103/a/kdb.php3
37. http://lwn.net/2002/0103/a/affix.php3
38. http://lwn.net/2002/0103/hviz.php3
39. http://lwn.net/2002/0103/a/uml.php3
40. http://lwn.net/2002/0103/a/uml-to-linus.php3
41. http://lwn.net/2002/0103/a/hviz.php3
42. http://lwn.net/2002/0103/a/drm.php3
43. http://lwn.net/2002/0103/a/hrt.php3
44. http://www.treblig.org/Linux_kernel_source_finder.html
45. http://kt.zork.net/kernel-traffic/kt20011231_148.html
46. http://lwn.net/2002/0103/a/voyager.php3
47. http://lwn.net/2002/0103/a/spc.php3
48. http://lwn.net/2002/0103/a/rmap-10.php3
49. http://lwn.net/2002/0103/a/rmap-10a.php3
50. http://lwn.net/2002/0103/a/befs.php3
51. http://lwn.net/2002/0103/a/rbf.php3
52. http://lwn.net/2002/0103/a/devfs.php3
53. http://lwn.net/2002/0103/a/devfs-205.php3
54. http://lwn.net/2002/0103/a/cryptoapi.php3
55. http://lwn.net/2002/0103/a/cml.php3
56. http://lwn.net/2002/0103/a/usagi.php3
57. mailto:lwn@lwn.net
58. http://kt.zork.net/
59. http://www.atnf.csiro.au/~rgooch/linux/docs/kernel-newsflash.html
60. http://www.kerneltrap.com/
61. http://www.osdl.org/archive/rddunlap/linux-port-25x.html
62. http://lksr.org/
63. http://www.tux.org/lkml/
64. http://www.linux.eu.org/Linux-MM/
65. http://lse.sourceforge.net/
66. http://www.kernelnewbies.org/
67. http://www.xml.com/ldd/chapter/book/index.html
68. http://lwn.net/2002/0103/dists.php3
69. http://www.eklektix.com/
70. http://www.eklektix.com/
--- ifmail v.2.14.os7-aks1
* Origin: Unknown (2:4615/71.10@fidonet)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
| Тема: |
Автор: |
Дата: |
|
URL: http://www.lwn.net/2002/0103/kernel.php3 |
Sergey Lentsov |
03 Jan 2002 18:20:50 |
|
|
