Kernel Traffic #196 by Zack Brown
[email protected] Mon, 16 Dec 2002 00:10:33 -0800
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <E18NqKf-0000W3-00@renegade> |
Kernel Traffic #196 For 16 Dec
By Zack Brown
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Mailing List Stats For This Week
* Threads Covered
1. 2 Dec - 9 Dec (20 posts) ACPI Fixes Delayed In 2.4
2. 2 Dec - 7 Dec (18 posts) Framebuffer Updates And Status
3. 3 Dec - 11 Dec (78 posts) Compatibility Syscall Layer
4. 4 Dec - 9 Dec (40 posts) The Future Of Kernel Development
5. 4 Dec - 7 Dec (90 posts) Non-PCI-Specific DMA API
6. 6 Dec - 9 Dec (11 posts) ACPI Licensing Change
7. 6 Dec (1 post) User-Mode Linux Updated To 2.5.50
8. 7 Dec (2 posts) Support For The Via 8633 AGP Card
9. 7 Dec (4 posts) Support For The Via 8233 Onboard Sound Card
10. 7 Dec - 9 Dec (5 posts) New IDE Subsystem Code Going Into 2.4 Tree
11. 9 Dec (1 post) Kernel Maintainer List
12. 10 Dec (1 post) POSIX Test Suite 0.1.0 Released
13. 10 Dec (1 post) Linux Test Project 20021210 Released
14. 10 Dec (1 post) New 2.5 Status List Released
15. 11 Dec (2 posts) procps 2.0.11 Released
Mailing List Stats For This Week
We looked at 1439 posts in 7640K.
There were 385 different contributors. 208 posted more than once. 161 posted
last week too.
The top posters of the week were:
* 61 posts in 170K by Alan Cox
* 46 posts in 221K by Andrew Morton
* 37 posts in 127K by William Lee Irwin III
* 36 posts in 772K by george anzinger
* 32 posts in 85K by "David S. Miller"
* Full Stats
1. ACPI Fixes Delayed In 2.4
2 Dec - 9 Dec (20 posts) Archive Link: "[BK PATCH] ACPI updates"
Andrew Grover announced:
Now that 2.4.20 is out, I'd like to work with you on getting the ACPI code
into 2.4.21-pre as soon as possible. This code has been continually tested
by the 500+ people on the acpi-devel mailing list, and has been merged with
2.5.x as improvements have been made.
I feel we have done due diligence to minimize any issues and early
inclusion in the prepatch series will give us time to address any that are
reported.
You may want to refer to: (sorry for the URL line breakage)
http://linux-acpi.bkbits.net:8080/linux-2.4-acpi/user=agrover/
ChangeSet@-6M? nav=!-|index.html|stats|!+|index.html (http://
linux-acpi.bkbits.net:8080/linux-2.4-acpi/user=agrover/ChangeSet@-6M?nav=!-
|index.html|stats|!+|index.html)
Except for the very earliest changeset, these are all the incremental
improvements we have been making over the last year. I count 69 substantive
changesets.
the bk url is: http://linux-acpi.bkbits.net/linux-2.4-acpi
Arjan van de Ven objected strongly to this patch, and asked Marcelo Tosatti not
to merge it. He explained, "This patch removes existing, small, working,
maintained functionality from the kernel and "replaces" it with something else
for which patches aren't even accepted and that is a lot bigger and less
readable code," and added, "Not only is it rude on the side of the ACPI people
to remove "competing" functionality, but it will break all kinds of existing
setups that now have to change the way they configure their system. In addition
it's not even needed, the existing code can live together with the code Andrew
proposes just fine as the United Linux kernel proves."
Andrew replied that the new code simply unified the 2.4 ACPI code with the code
that had been in 2.5 for a long time. He asked, "Is your concern with the code,
or the cmdline option? We could certainly keep the same cmdline option "acpismp
=force" if that is the issue, but that always seemed like kind of a strange
name for the option, to me." Alan Cox replied, "strange or otherwise - changing
it in 2.4 is a bad idea - keeping it as well as the 2.5 option is safer. 2.4
should continue to work on upgrades as people expected it to - conservatism is
the key. I think thats why Arjan is arguing as he does." And Arjan also replied
to Andrew, saying, "actually my biggest concern is that you break existing
setups, or at least change it more than needed. There is ZERO need to remove
the existing working (and lean) code, even though your code might also be able
to do the same. It means people suddenly need to change all kinds of config
options, it's different code so will work slightly different... unifying 2.5 is
nice and all but there's no need for that here since both implementations can
coexist trivially."
Andrew asked if the best option would be to use the patch from the United Linux
kernel, and move incrementally from there to make any other desired changes.
But Arjan said no, all that was necessary was to replace the code Andrew's
initial ACPI patch removed. There was no need to abandon the entire patch.
At this point there was a bit of back-room maneuvering, and Andrew said:
Well after communicating with Marcelo it sounds like he'd like to hold off
taking it in 2.4.21 because IDE changes take priority, and two big changes
at once is too many for a stable kernel revision.
Fair enough. I'm just worried that 2.4.22 is a long ways away.
Maybe one way to address Marcelo's stability concerns and Arjan's "keep
acpitable.[ch] around" preference is for me to submit a patch that I *know*
don't affect anything besides ACPI -- i.e. only the changes that have been
made under drivers/acpi, and then go from there, submitting UL-derived and
other improvements incrementally after that.
He asked if this seemed like the right approach to folks, and Pavel Machek
replied that yes, "Its certainly better than no ACPI update at all." However,
Hanno Boeck was very disappointed with the delay. He said, "In my opinion, the
ACPI-patch is the most-needed kernel-patch at the moment. For many laptop-users
that don't know about this patch, Linux is nearly unuseable. And I already know
at least two desktop-pcs that don't have any power-management without the
acpi-patch. Andrew, I hope you can find a way to make a patch that the
kernel-people will accept as soon as possible." Arjan replied that, since 2.4
didn't actually offer suspend/resume capabilities, there didn't seem to be any
pressing need for these patches. But Matthew Wilcox and Alan pointed out that
without them, many systems wouldn't even boot. Marcelo asked which systems were
affected by these problems. Alan said, "New compaqs, existing xmeta, new HP
wont boot without the -ac IDE and the workarounds for ATi or fixes for ALi IDE.
(Users should try to avoid the ati igp stuff for now btw - no X support, no pci
routing support, most kernels wont run on it, no docs)." Matthew also added,
"hp's zx1-based ia64 machines (my personal interest..) and i thought some
laptops required updated ACPI to boot. also, aren't there some SMP x86 boxes
with buggy bios tables that won't boot without ACPI?" Jeff Garzik added, "There
are several classes of machines that require ACPI to boot... a big question is
whether these machines need full ACPI or just acpitable.c, too..."
Arjan pointed out that at least HP's zx1-based ia-64 machines also required
several other patches in order to boot, but Bjorn Helgaas replied, "Apart from
ACPI, the non-ia64 patches required to boot a zx1 should be relatively small:
some IRQ changes, support in memmap_init for discontiguous memory, etc." And
added, "Having a newer ACPI in 2.4.x (it currently has 20011018!) would make
things much easier for ia64."
2. Framebuffer Updates And Status
2 Dec - 7 Dec (18 posts) Archive Link: "[STATUS] fbdev api."
James Simmons announced:
I have a new patch avaiable. It is against 2.5.50. The patch is at
http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
Have fun!!!!
Drivers ported are: (Give them a try)
ATI Mach 64
ATI 128
VESA
VGA16
HGA
NIVIDA
NEOMAGIC
The BIG changes are:
1. The seperation of the console code out of the fbdev drivers.
2. Total modularity of the frmaebuffer console system. Yes that is right.
You can build it has modules. Great for testing.
The following are results of the new changes which I have tested.
With my VIA laptop with my neomagic card I was able to build it with vgacon
and no fbcon. Then I insmod neofb and the soft accel (cfb*.c) needed. It
loading and did NOT change the video hardware state. At this point I could
run fbdev apps including a X server using /dev/fb solely. On opening /dev/
fb0 the graphics hardware state changed. In theory I could exit X and get
vgacon back. In order to do this I have to reset the hardware back to vga
text mode in the fb_release function. It can be done but I haven't done it
yet.
With the second experiment I was able to insmod the fonts and fbcon.o. Then
it switched from vgacon to fbcon. In theory I could again call the release
function and reset the hardware back to a text mode state. All that is
needed is the hardware specific code to do this.
Things to be done:
1. A few bugs in fbcon to hammer out.
2. Fbcon to support changing resolution via the console layer.
3. Move the logo code out of fbcon.c to fbmem.c. With pure fbdev you need
something to let you know things worked.
4. Software rotation.
Christoph Hellwig asked, "Any chance you could sync with linus again? fb in
mainline is pretty rotten." And James said, "I think the time has come. Alot of
improvmenents have happened :-) The final api for the low level drivers is
done. Any further changes will be in fbmem.c and fbcon. I just synced up the
latest work."
3. Compatibility Syscall Layer
3 Dec - 11 Dec (78 posts) Archive Link: "[PATCH] compatibility syscall layer
(lets try again)"
Stephen Rothwell said:
Below is the generic part of the start of the compatibility syscall layer.
I think I have made it generic enough that each architecture can define
what compatibility means.
To use this,an architecture must create asm/compat.h and provide typedefs
for (currently) compat_time_t, compat_suseconds_t, struct compat_timespec.
Hopefully, this is what you had in mind - ohterwise back to the drawing
board.
I will follow this posting with the architecture specific patches that I
have done but not tested.
There was general applause, and Linus Torvalds also approved, though he had
some cosmetic complaints. In the course of an implementation discussion, Linus
made the following related remark:
Alpha (and apparently sparc) simply do not save the registers that the
signal handling wants on the stack _at_all_. There are too many registers
to save at each system call entry point, and 99% of all system calls never
need it.
The system call return that checks for signals anyway will end up saving a
special stack frame when needed. As will the special signal-related system
calls (sigsuspend() and friends). All of this is not only architecture-
dependent, it is literally coded in assembly language for the
architectures. See "do_switch_stack()" for alpha.
Anyway, if you wondered why Linux beats every other Unix out there on
system call overhead, now you know. And yes, this is important.
4. The Future Of Kernel Development
4 Dec - 9 Dec (40 posts) Archive Link: "is KERNEL developement finished, yet
???"
Shane Helms asked if low-level kernel development had reached its end, and if
Linux would henceforth develop only in the peripheral areas of optimization,
slight enhancements, security, and things of that kind. On linux-kernel, there
was a general tittering of laughter at this, and folks assured Shane that there
was still much to be done. Amidst this reassurance, Shane argued, "if you're
implying that we can start once again from bottom, and come up with something
better that unix (which has been opensource, around for long while, tested and
developed by many as well) I _HIGHLY_ doubt, and disagree. This is unless main
kernel developers *confess* that some incorrect design decisions were made at
the start (at a major section or so), which now they're forced to comply with,
and let such bugs traverse through kernel versions, and there is no way to
remove them, unless start from scratch again." Joseph D. Wagner replied:
Yes and no.
Unix (and Linux) developers are far too concerned with clinging to the
30-year-old outdated POSIX standard, which creates numerous problems when
trying to advance new features. For example, the POSIX standard is the
reason we have the three-by-three secure permissions on files (three users:
owner, group, everyone; three permissions: read, write, execute) instead of
Access Control Lists (ACL's).
Linus Torvalds replied:
No.
Only stupid people think they should throw away old proven concepts. What
happens quite often in academia in particular is that you find a problem
you want to fix, and you re-design the whole system around your fix.
This is how we get crap like microkernels. They have "an agenda", and
that's the _worst_ thing you can have when designing software. You fixate
on some perceived problem, and the end result is that yes, maybe you fixed
_that_ problem, but in the meantime you also generated a whole new of
issues - usually things that were solved by the original approach.
The UNIX/Linux approach is a very pragmatic thing - leave the things that
work well alone. There's no point in re-inventing the whole system just
because of some small perceived flaws.
Shane asked, "since we're not changing much in kernel core, and developement
implies adding additional code and layers for security, enhancements and
support for further hardware and etc. Does this not slow down the kernel ? or
is the execution code still the same ??" And Linus replied:
Oh, some things do get slower. We try to avoid hitting the critical paths,
and supporting new hardware for example (which tends to be a large portion
of kernel development, even if it isn't as sexy as new features) doesn't
impact the rest of the kernel negatively at all.
What we'll probably see in 2.6.x for example, is that many microbenchmarks
show slight deprovement (fork() and execve() have become noticeably slower
due to the rmap patches), but to at least somewhat offset that we get much
nicer worst-case behaviour and better scalability.
And many things _can_ be done without throwing out old designs.
Implementation improvements are quite possible without trying to make
something totally new to the outside. That's how things like the dcache
come about, for example - keeping the standard old boring UNIX filesystem
approach, while internally caching it in new ways, improving performance
tremendously.
Not throwing out the baby with the bath-water doesn't mean that you cannot
improve the system. I'm only arguing against stupid people who think they
need a revolution to improve - most real improvements are evolutionary.
5. Non-PCI-Specific DMA API
4 Dec - 7 Dec (90 posts) Archive Link: "[RFC] generic device DMA
implementation"
James Bottomley proposed:
Currently our only DMA API is highly PCI specific (making any non-pci bus
with a DMA controller create fake PCI devices to help it function).
Now that we have the generic device model, it should be equally possible to
rephrase the entire API for generic devices instead of pci_devs.
This patch does just that (for x86---although I also have working code for
parisc, that's where I actually tested the DMA capability).
The API is substantially the same as the PCI DMA one, with one important
exception with regard to consistent memory:
The PCI api has pci_alloc_consistent which allocates only consistent memory
and fails the allocation if none is available thus leading to driver
writers who might need to function with inconsistent memory to detect this
and employ a fallback strategy.
The new DMA API allows a driver to advertise its level of consistent memory
compliance to dma_alloc_consistent. There are essentially two levels:
+ I only work with consistent memory, fail if I cannot get it, or
+ I can work with inconsistent memory, try consistent first but return
inconsistent if it's not available.
The idea is that the memory type can be coded into dma_addr_t which the
subsequent memory sync operations can use to determine whether wback/
invalidate should be a nop or not.
Using this scheme allows me to eliminate all the inconsistent memory
fallbacks from my drivers.
Adam J. Richter replied:
I'd really like to see a change like yours integrated soon to stop the
spread of fake PCI devices (including the pcidev==NULL convention) and
other contortions being used to work around this. Also, such a change would
enable consolidation of certain memory allocations and their often buggy
error branches from hundred of drivers into a few places.
As you know, I posted a similar patch that created a new field in struct
bus_type, as Miles Bader suggested just now, although only for {alloc,free}
_consistent. if the bus-specific variation can be confined to some smaller
part of these routines or eliminated, then I'm all in favor of skipping the
extra indirection and going with your approach. It will be interesting to
see if your model allows most of the sbus_ and pci_ DMA mapping routines in
sparc to be merged. I suspect that you will have to adopt some kind of
convention, such as that device->parent->driver_private will have a common
meaning for pci and sbus device on that platform.
Jeff Garzik also offered his support, saying, "I'm glad James is doing this
work, it will clean up a lot of assumptions and corner-case-uglies..."
A big pile of developers swarmed around the technical details for awhile,
discussing naming, architecture, and other issues. At one point Russell King
offered some technical objections and remarked that the implementation would
get so ugly, that "I'd rather keep our existing pci_* API than be forced into
this crap." To which James replied:
Let me just clarify: I'm not planning to revoke the pci_* API, or to
deviate substantially from it. I'm not even planning to force any arch's to
use it if they don't want to. I'm actually thinking of putting something
like this in the asm-generic implementations:
dma_*(struct device *dev, ...) {
BUG_ON(dev->bus != &pci_bus_type)
pci_*(to_pci_device(dev), ..)
}
The whole point is not to force another massive shift in the way drivers
are written, but to provide a generic device based API for those who need
it. There are very few drivers that actually have to allocate fake PCI
devices today, but this API is aimed squarely at helping them. Drivers that
only ever see real PCI devices won't need touching.
6. ACPI Licensing Change
6 Dec - 9 Dec (11 posts) Archive Link: "Proposed ACPI Licensing change"
Andrew Grover reported:
The ACPI AML interpreter (i.e. code in directories under drivers/acpi, but
not source in drivers/acpi directly) has been released by us (Intel) under
the GPL. It has also been released separately under a looser license, so
that other OS vendors may make use of it.
One consequence of this is that we have not been able to benefit directly
from patches from other Linux contributors. The reason is, patches
submitted to code only under the GPL must also be GPL, and therefore we
cannot take them directly and still make our code available under a license
other than the GPL. (We have to determine the problem the patch fixes and
then do the fix ourselves.)
This has slowed development and lessened community participation in the
development process.
In order to solve this, we are considering releasing the Linux version of
the interpreter under a dual license. This would allow direct incorporation
of changes. Any patches submitted against the ACPI core code would
implicitly be allowed to be used by us in a non-GPL context. This is
already done elsewhere in the Linux kernel source by the PCMCIA code, for
example.
Christoph Hellwig was fine with this, and suggested, "Please use a known
license for the second option, i.e. MPL." Alan Cox was also fine with Andrew's
proposal, saying:
I think this is an extremely good idea. I certainly would have no problem
contributing cleanup/fixes to the project under those terms. And if I did
something large and mega cool with ACPI I can still GPL it only and you can
still ignore it 8)
There is a tradition of contributing patches back under the license the
project you are contributing to used (and ACPI is certainly big enough to
be 'a project' not just a patch)
Suits me fine
Jeff Garzik also approved, saying:
Since pcmcia already set an example with their license, I think it's a
great model to follow.
I also echo other comments to choose an already-known license like the MPL
or BSD (etc.) so that lawyers don't have extra work ;-)
Greg KH was also fine with Andrew's proposal. Elsewhere, Adrian Bunk replied to
Andrew's initial proposal:
two comments regarding the right of an author to freely choose under which
license(s) he wants to make his patch available:
If a submitter wants to allow you to use his patch under both licenses he's
already able to allow you to do so.
You can't forbid people to send GPL-only patches, so if a person doesn't
want his patch under your looser license you can't enforce that he also
releases it under your looser license.
Linus Torvalds replied:
That's true, but on the other hand we've had these dual-license things
before (PCMCIA has been mentioned, but we've had reiserfs and a number of
drivers like aic7xxx too), and I don't think I've _ever_ gotten a patch
submission that disallowed the dual license.
In fact, I don't think I'd even merge a patch where the submitter tried to
limit dual-license code to a simgle license (it might happen with some
non-maintained stuff where the original source of the dual license is gone,
but if somebody tried to send me an ACPI patch that said "this is GPL
only", then I just wouldn't take it).
I suspect the same "refuse to accept license limiting patches" would be
true of most kernel maintainers. At least to me a choice of license by the
_original_ author is a hell of a lot more important than the technical
legality of then limiting it to just one license.
So yes, dual-license code can become GPL-only, but not in _my_ tree.
Somebody else can go off and make their own GPL-only additions, and quite
frankly I would find it so morally offensive to ignore the intent of the
original author that I wouldn't take the code even if it was an improvement
(and I've found that people who are narrow-minded about licenses are
narrow-minded about other things too, so I doubt it _would_ be an
improvement).
H. Peter Anvin remarked, "This is good. I'd like to keep klibc under a BSD/GPL
license because some people (e.g. Al Viro) have issued concerns about making a
nondynamic user-space library GPL or LGPL, and I pretty much agree with their
concerns. The current klibc tarball isn't completely "untainted", since it
contains "fixed"/modified kernel headers in a few places, but I'm hoping to
migrate those changes back into the kernel headers proper once the merge is
done."
7. User-Mode Linux Updated To 2.5.50
6 Dec (1 post) Archive Link: "uml-patch-2.5.50-1"
Jeff Dike announced:
This patch updates UML to 2.5.50. As far as UML itself is concerned, this
is identical to 2.5.49.
NOTE: I get reproducable filesystem corruption with this version. Offhand,
it doesn't look like my fault, so I'm releasing it anyway. I didn't notice
any such complaints (or fixes) about 2.5.50 on lkml, but it's possible I
wasn't paying enough attention. If there is a fix, apply it first. If not,
then run this version on a filesystem that you can afford to have trashed.
The 2.5.50 UML patch is available at
http://uml-pub.ists.dartmouth.edu/uml/uml-patch-2.5.50-1.bz2
For the other UML mirrors and other downloads, see
http://user-mode-linux.sourceforge.net/dl-sf.html
Other links of interest:
The UML project home page : http://user-mode-linux.sourceforge.net
The UML Community site : http://usermodelinux.org
8. Support For The Via 8633 AGP Card
7 Dec (2 posts) Archive Link: "[PATCH 2.4.20] Via AGP 8633"
Nathaniel Russell announced, "This patch add's support for the Via 8633 AGP
Card." He added, "it is diffed against Linux Kernel-2.4.20 and most likely
applies to current 2.5.x series kernel."
9. Support For The Via 8233 Onboard Sound Card
7 Dec (4 posts) Archive Link: "[PATCH 2.4.20] Via 8233 Sound Support"
Nathaniel Russell announced, "This patch adds support for the Via8233 Onboard
Sound Card. This patch applies to Linux Kernel 2.4.20 cleanly. The only file
this patch touch's is drivers/sound/via82cxxx_audio.c. Please apply to current
Linux Kernel 2.4.x" But Jeff Garzik replied, "unfortunately this only works
sporadically, and only for some motherboards. There is a reason why I removed
this pci id from the driver, after foolishly adding it :)" In a later post, he
suggested, "Dave Jones did a really nice cleanup of agpgart in 2.5, so even
though there is no agpgart MAINTAINERS entry, I think he would be a good target
for patches :) Even thought 2.5 agpgart is clearly different, davej has a clue
about it and could probably ack or apply 2.4 patches..."
10. New IDE Subsystem Code Going Into 2.4 Tree
7 Dec - 9 Dec (5 posts) Archive Link: "[PATCH 2.4.20-BK] Needed patch to
build ide-scsi with new IDE -ac merge"
Marc-Christian Petersen posted an IDE patch for 2.4, and J.A. Magallon asked,
"does this mean that Andre's ide is going into 2.4.21-pre1 ?" Marc-Christian
confirmed that this was indeed the case, with a big, "finally!!!!!!!!! :-))"
Alan Cox also confirmed this, and added, "though various bits seem to have
vanished in the submission (system.h bits and ide-scsi). Davem has some follow
up bits I need to apply (the new IDE broke some weird 64bit bigendian platform
that he supports 8))"
11. Kernel Maintainer List
9 Dec (1 post) Archive Link: "lk maintainers"
Denis Vlasenko posted his most recent list of kernel maintainers (http://
www.uwsg.indiana.edu/hypermail/linux/kernel/0212.1/0159.html) , saying:
This document is mailed to lkml regularly and will be modified whenever new
victim wishes to be listed in it or someone can no longer devote his time
to maintainer work.
If you want your entry added/updated/removed, contact me.
BTW, requests to move your entry to the top of the list without actually
changing the text are fine too: that will indicate that entry is not
outdated, so don't be shy ;-)
12. POSIX Test Suite 0.1.0 Released
10 Dec (1 post) Archive Link: "[ANNOUNCE] POSIX Test Suite 0.1.0 released"
Julie N Fleischer announced:
Release 0.1.0 of the Open POSIX Test Suite is now available at http://
posixtest.sourceforge.net. This early release contains only a small amount
of the initial testing goals. It contains conformance tests for POSIX
Timers, tags TMR and CS (except THR CS). The release notes that appear when
downloading the project describe where to find information on compiling and
running the test cases.
The README page and the Open POSIX Test Suite website (above) give more
information on the project goals and progress as well as information on how
to contribute or contact us if you are interested.
The Open POSIX Test Suite is an open source test suite with the goal of
performing conformance, functional, and stress testing of the functions
described in the IEEE Std 1003.1-2001 System Interfaces specification.
Eventual testing of the full specification is desired; however, initial
work is focusing on Timers, Message Queues, Threads, Semaphores, and
Signals.
13. Linux Test Project 20021210 Released
10 Dec (1 post) Archive Link: "[ANNOUNCE] ltp-20021210 released."
Jeff Martin announced:
The Linux Test Project test suite LTP-20021210.tgz has been released. Visit
our website (http://ltp.sourceforge.net) to download the latest version of
the testsuite, and for information on test results on pre-releases, release
candidates & stable releases of the kernel. There is also a list of test
cases that are expected to fail, please find the list at (http://
ltp.sourceforge.net/expected-errors.php)
The highlights of this release are:
+ Many new test from Wipro.
+ New SPIE tests ported. Special thanks to Gerrit Huizenga and Narasimha
Sharoff for getting us the SPIE tests.
We encourage the community to post results, patches, or new tests on our
mailing list, and to use the CVS bug tracking facility to report problems
that you might encounter. More details available at our web-site.
14. New 2.5 Status List Released
10 Dec (1 post) Archive Link: "[STATUS 2.5] December 11, 2002"
Guillaume Boissiere posted his latest 2.5 Status List ( ) , saying:
The stabilization work has begun. One item of interest this week is the
update to the new framebuffer/console API. Full list is available at http:/
/www.kernelnewbies.org/status/
Also, with more people testing different configurations, the number of bugs
in bugzilla has increased quite a big since last week. 80 and counting.
15. procps 2.0.11 Released
11 Dec (2 posts) Archive Link: "[announce] procps 2.0.11"
Robert Love announced:
Rik and I are pleased to announce version 2.0.11 of procps, the package
that contains ps, top, free, vmstat, etc.
Newer versions of procps are required for 2.5 kernels.
Most notable in this release is a handful of bug fixes, support for /proc/
pid/wchan, and an all-new free(1) implementation.
Source tarball and RPM packages are available from:
http://tech9.net/rml/procps/
Procps discussion, bugs, and patches are welcome at:
[email protected]
NEWS for 2.0.11:
+ add CPU field to top (Dave Miller)
+ ensure top CPU stat spacing is always aligned (Rik van Riel)
+ vmstat divide by zero fix (Jens Axboe)
+ support pre-decoded wchan from 2.5 in /proc/#/wchan (Robert Love)
+ Makefile cleanups (Maciej W. Rozycki)
+ removed XConsole from the package (Robert Love)
+ removed kill and kill.1 - they are in util-linux (Robert Love)
+ provide crucial typo fixes (Chris Rivera)
+ all-new implementation of free (Robert Love)
+ improved print_uptime and sprint_uptime (Robert Love)
+ default install permissions are now 755 (Robert Love)
We Hope You Enjoy Kernel Traffic
All Kernel Traffic and Cousin issues and summaries are copyright their original
authors, and distributed under the terms of the
GNU General Public License, version 2.0.