Kernel Traffic #320 by Zack Brown
[email protected] Wed, 31 Aug 2005 07:52:50 -0700
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <[email protected]> |
Kernel Traffic #320 For 28 Aug
By Zack Brown
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Mailing List Stats For This Week
* Threads Covered
1. 12 Jul - 21 Jul (18 Linux 2.6.13-rc3 Released; Status Of Default HZ
posts) Value
2. 13 Jul - 17 Jul (25 Patch Review For Linux 2.6.12.3; Some
posts) Developers Unhappy With Acceptance Policies
3. 14 Jul - 15 Jul (9 New Linux Kernel Performance Project
posts)
4. 15 Jul (1 Guide To Using git
post)
5. 15 Jul - 16 Jul (3 Linux 2.6.12.3 Released
posts)
6. 18 Jul - 19 Jul (8 Some Advice For New Kernel Hackers
posts)
7. 18 Jul (4 DevFS Author Speaks In Favor Of DevFS After
posts) Long Silence
8. 20 Jul (1 New patchview Script For Better Review
post)
Mailing List Stats For This Week
We looked at 1878 posts in 11MB.
There were 577 different contributors. 230 posted more than once. The average
length of each message was 95 lines.
+-----------------------------------------------------------------------------+
|The top posters of the | The top subjects of the week were: |
| week were: | |
|-----------------------+-----------------------------------------------------|
|138 posts in 612KB by |194 posts in 840KB for "[patch] i386: selectable |
|ingo molnar |frequency of the timer interrupt" |
|85 posts in 486KB by |123 posts in 916KB for "[patch] real-time preemption,|
|olaf hering |-rt-2.6.12-rc6-v0.7.48-00" |
|62 posts in 222KB by |99 posts in 607KB for "realtime preemption, 2.6.12, |
|lee revell |beginners guide?" |
|38 posts in 161KB by |65 posts in 316KB for "real-time preemption, |
|russell king |-rt-2.6.12-final-v0.7.50-24" |
|35 posts in 275KB by |24 posts in 107KB for "[patch] ramfs: pretend dirent |
|william weston |sizes" |
+-----------------------------------------------------------------------------+
Full Statistics generated by mboxstats version 2.8
1. Linux 2.6.13-rc3 Released; Status Of Default HZ Value
12 Jul - 21 Jul (18 posts) Archive Link: "Linux v2.6.13-rc3"
Topics: FS: ReiserFS, Kernel Release Announcement, Ottawa Linux Symposium,
Power Management: ACPI, Sound: MIDI
People: Linus Torvalds, Lee Revell, Dmitry Torokhov
Linus Torvalds announced Linux 2.6.13-rc3, saying:
Yes, it's _really_ -rc3 this time, never mind the confusion with the commit
message last time (when the Makefile clearly said -rc2, but my over-eager
fingers had typed in a commit message saying -rc3).
There's a bit more changes here than I would like, but I'm putting my foot
down now. Not only are a lot of people going to be gone next week for LKS
and OLS, but we've gotten enough stuff for 2.6.13, and we need to calm
down.
Admittedly the diff looks a bit bigger than it really conceptually is,
partly due to the hwmon drivers moving around, partly due to re-indenting
reiserfs. No real changes, but huge diffs in both cases.
Dmitry Torokhov noticed that he'd been credited with a patch to nable EC Burst
Mode in ACPI, while Luming Yu had really done the work. He piped up to give
credit where credit was due.
Elsewhere, Lee Revell remarked, "HZ still defaults to 250. As was explained in
another thread, this will break apps like MIDI sequencers and won't really save
much battery power. The default should remain 1000 until these issues are
resolved." But Linus replied:
Stop bothering with this, I've seen the thread, and no, I disagree totally
with "as explained in another thread". That's simply not true.
The only thing that is true is that 100Hz is too low for some use, and
1000Hz is too high for some uses. NOBODY has shown that 250Hz isn't good
enough, there's only been people whining and complaining and saying it
might not be.
The fact is, engineering is about finding something that works "well
enough". If _you_ think that 1000Hz is the right answer, then _you_ select
that. But if you cannot accept the fact that other people are of a
different opinion, then why would anybody want to discuss the issue with
you?
This is a fundamental fact of engineering (and, in fact, pretty much any
other area in life):
If you cannot accept that other people have other aims and needs than
than you, then why are you talking to other people in the first place?
So get on with your lives. Realize that there is no "perfect" value for HZ.
250 right now is somewhere reasonable, and for the extreme ends you can
always chose your own. Don't try to force your ideas on others.
And btw, the next time somebody complains about HZ, I want HARD DATA. I
don't want whining. Stop cc'ing me in you don't have a real datapoint, and
if you cannot accept that other people have _other_ real datapoints.
Lee replied, "OK, point taken, I'm done with this issue as far as LKML is
concerned. Anyone who wants to discuss this further can come over to the
linux-audio-dev list."
2. Patch Review For Linux 2.6.12.3; Some Developers Unhappy With Acceptance
Policies
13 Jul - 17 Jul (25 posts) Archive Link: "[00/11] -stable review"
Topics: SMP
People: Greg KH, Francois Romieu, Adrian Bunk, Ralf Baechle
Greg KH announced:
This is the start of the stable review cycle for the 2.6.12.3 release.
There are 11 patches in this series, all will be posted as a response to
this one. If anyone has any issues with these being applied, please let us
know. If anyone is a maintainer of the proper subsystem, and wants to add a
signed-off-by: line to the patch, please respond with it.
These patches are sent out with a number of different people on the Cc:
line. If you wish to be a reviewer, please email [email protected] to add
your name to the list. If you want to be off the reviewer list, also email
us.
Responses should be made by Friday, July 15, 20:00:00 UTC 2005. Anything
received after that time, might be too late.
One of the patches had this changelog entry: "Drivers really only work well in
SMP if they actually can be selected. This is a leftover from the time when the
6pack drive only used to be a bitrotten variant of the slip driver." Francois
Romieu asked:
Is the guideline above from 28/04/2005 obsoleted ?
+ It must fix a problem that causes a build error (but not for things
marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
security issue, or some "oh, that's not good" issue. In short,
something critical.
Greg replied, "It lets the driver be built, when it previously could not be,
unless the user used a config option that almost no one does... That's pretty
critical if you ask me." But Adrian Bunk said:
I do agree with Francois regarding this issue:
AFAIR, there has been not one 2.6 kernel where this driver was available
for SMP kernels. It's therefore untested which problems might arise with
this driver on SMP systems. I'm not arguing against including this driver
in 2.6.13, but 2.6.12.3 isn't the right place.
What surprises me most is that you accepted this patch is neither in
2.6.13-rc3 nor in 2.6.13-rc3-mm1. There seems to be either an (IMHO
unfortunate) change in your policy of what patches to accept, or there's a
serious problem in your patch review process.
Ralf Baechle argued that the patch was good, and that the unavailability of the
working driver was justification enough; but there was no further discussion.
3. New Linux Kernel Performance Project
14 Jul - 15 Jul (9 posts) Archive Link: "[announce] linux kernel performance
project launch at sourceforge.net"
Topics: Virtual Memory
People: Kenneth W. Chen, Andi Kleen, Randy Dunlap
Kenneth W. Chen said:
I'm pleased to announce that we have established a linux kernel performance
project, hosted at sourceforge.net:
http://kernel-perf.sourceforge.net
As much as discussed various time in the past on LKML that Linux kernel
needs a systematic and disciplined way to measure and track kernel
performance on a regular basis. To do that, we decided to run a large set
of benchmarks covering core components of the Linux kernel (virtual memory
management, I/O subsystem, process scheduler, file system, network, device
driver, etc) on a regular basis. Benchmarks are run on a variety of
platforms (4P Intel Xeon processor, 2P Xeon, several ia64 server boxes etc)
every week, measuring the latest snapshot of Linus' git development tree.
Comprehensive performance data from our tests will be published for easy
access.
Our goal is to work with the Linux community to further enhance the
performance of the Linux kernel. The data available on the site allows
community members to closely track performance gains and losses with every
version of the kernel. Ultimately, we hope that this data will result in
performance increases in Linux kernel development.
The benchmark result pages are populated with a few benchmarks at the
moment. In the coming weeks, we will be populating more benchmark data.
Happy surfing and hacking!!
Andi Kleen replied:
That's very cool. Thanks a lot.
Would it be possible to add 2.4.30 numbers and perhaps one or two distro
kernels (let's say RHEL3/4, SLES8/9) to the graphs as data points for
comparison? These are all very tuned kernels and would show where mainline
is worse than them.
Also how did you run netperf? Locally or to some other machine? Perhaps
that should be documented.
Some oprofile listings from a few of the test runs would be also nice.
Kenneth replied that they'd decided to go with mainline kernels for
consistency, but they'd look into adding distibution kernels as well. Regarding
netperf, Kenneth confirmed that it was run locally, and said he'd document that
fact. Regarding oprofile listings, Kenneth said, "That is in the works. We will
upload profile data. I'm having problem with oprofile on some versions of
kernel and that is being investigated right now." Andi said, "If you run
statically compiled kernels you could as well use the old style readprofile. It
just doesn't work with modules." And Randy Dunlap put in, "It can be made to
work with modules (and has been against 2.6.6 (http://developer.osdl.org/
rddunlap/modprofile/) ), but I'd just stick with not using modules, given a
choice."
4. Guide To Using git
15 Jul (1 post) Archive Link: "Kernel Hacker's guide to git (updated)"
People: Jeff Garzik
Jeff Garzik said:
I've updated my git quickstart guide at
http://linux.yyz.us/git-howto.html
It now points to DaveJ's daily snapshots for the initial bootstrap tarball,
is reorganized for better navigation, and other things.
Also, a bonus recipe: how to import Linus's pack files (it's easy).
This recipe presumes that you have a vanilla-Linus repo (/repo/linux-2.6)
and your own repo (/repo/myrepo-2.6).
$ cd /repo/myrepo-2.6
$ git-fsck-cache # fsck, make sure we're OK
$ git pull /repo/linux-2.6/.git # make sure we're up-to-date
$ cp -al ../linux-2.6/.git/objects/pack .git/objects
$ cp ../linux-2.6/.git/refs/tags/* .git/refs/tags
$ git-prune-packed
$ git-fsck-cache # fsck #2, make sure we're OK
This recipe reduced my kernel.org sync from ~50,000 files to ~5,000 files.
5. Linux 2.6.12.3 Released
15 Jul - 16 Jul (3 posts) Archive Link: "Linux 2.6.12.3"
Topics: Ioctls, Networking, PCI, Power Management: ACPI, SMP
People: Greg KH, Ralf Baechle, David S. Miller, Patrick McHardy, Alexander
Nyberg
Greg KH announced Linux 2.6.12.3, saying:
We (the -stable team) are announcing the release of the 2.6.12.3 kernel.
The diffstat and short summary of the fixes are below.
I'll also be replying to this message with a copy of the patch between
2.6.12.2 and 2.6.12.3, as it is small enough to do so.
The updated 2.6.12.y git tree can be found at:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/linux-2.6.12.y.git
and can be browsed at the normal kernel.org git web browser:
www.kernel.org/git/
----------
Makefile | 2
arch/ppc/kernel/time.c | 13 ++--
arch/um/kernel/process.c | 48 ++++++++++-------
drivers/acpi/pci_irq.c | 2
drivers/char/tpm/tpm.c | 76 ---------------------------
drivers/char/tpm/tpm.h | 2
drivers/char/tpm/tpm_atmel.c | 16 +++--
drivers/char/tpm/tpm_nsc.c | 16 +++--
drivers/char/tty_ioctl.c | 4 -
drivers/media/video/cx88/cx88-video.c | 2
drivers/net/hamradio/Kconfig | 2
drivers/net/shaper.c | 40 +++++---------
fs/char_dev.c | 2
include/linux/if_shaper.h | 2
net/ipv4/ip_output.c | 3 -
net/ipv4/netfilter/ip_conntrack_standalone.c | 7 ++
net/packet/af_packet.c | 6 ++
17 files changed, 93 insertions(+), 150 deletions(-)
Summary of changes from v2.6.12.2 to v2.6.12.3
==============================================
Alexander Nyberg:
If ACPI doesn't find an irq listed, don't accept 0 as a valid PCI irq.
David S. Miller:
fix Shaper driver lossage in 2.6.12
Greg Kroah-Hartman:
Linux 2.6.12.3
john stultz:
ppc32: stop misusing ntps time_offset value
KAMBAROV, ZAUR:
coverity: tty_ldisc_ref return null check
Kylene Jo Hall:
tpm breaks 8139cp
Michael Krufky:
v4l cx88 hue offset fix
Paolo 'Blaisorblade' Giarrusso:
uml: fix TT mode by reverting "use fork instead of clone"
Patrick McHardy:
revert nf_reset change
Ralf Baechle:
SMP fix for 6pack driver
Wen-chien Jesse Sung:
fix semaphore handling in __unregister_chrdev_region
6. Some Advice For New Kernel Hackers
18 Jul - 19 Jul (8 posts) Archive Link: "how to be a kernel developer ?"
Topics: FS: NFS
People: Jesper Juhl, Brian O'Mahoney, Alessandro Rubini, Jonathan Corbet,
Robert Love
Someone asked about how to be a kernel developer, and several folks replied
with suggestions. Jesper Juhl said:
A few things you should do :
+ Take a look in the Documentation/ directory in the kernel source,
you'll find lots of valuable information there.
+ Go check out http://kernelnewbies.org/
+ You may also find this online source browser useful (I know I do) http:
//lxr.linux.no/
+ Keep a link to a LKML archive in your bookmarks and search the archives
for answers whenever you have a question - chances are good that
whatever you want to ask has been asked before and answered in depth on
the list, so it'll be in the archives. Here's one LKML archive you can
use, it goes back a few years : http://www.ussg.iu.edu/hypermail/linux/
kernel/
+ Subscribe to LKML and start reading the some of the threads. A lot can
be learned by reading the bugreports and solutions that pop up on the
list, there are also often discussions on ideas, implementation
details, debugging etc etc that can be valuable. So join the list and
start listening :) ohh, and do read the lists FAQ at http://www.tux.org
/lkml/
+ You may also want to join the Linux Kernel Janitors http://
janitor.kernelnewbies.org/ - they have a mailing list and a nice TODO
list of things that need doing - good place to pick a small starting
project from.
+ You should also, most likely, invest in a few books on the kernel and
read them. I'd recommend these two as good ones to start with : "Linux
Kernel Development (2nd Edition), by Robert Love" and "Linux Device
Drivers (Third Edition), by Jonathan Corbet, Alessandro Rubini, and
Greg Kroah-Hartman".
+ And most important of all, start reading the kernel source, and play
with the kernel source. Reading the source, making some changes and
then testing them and learning from the mistakes you make is a great
way to learn.
He added in another email:
You can also help out by testing the development kernels - they need
testing by as many people as possible, so start testing the -rc kernels and
the daily git snapshots as well as the -mm kernels. Test if they build with
your usual configuration, test if they build with "allnoconfig",
"allyesconfig", "allmodconfig" and perhaps a random config or two. Test if
they boot OK, if they run OK for a longer time, etc.
When you find a problem you can try to fix the issue yourself and send a
patch to both the mailinglist and the person responsible for the code in
question. If you are unable to fix the problem yourself, then send a
detailed bugreport to the list and the person responsible for the code.
Take a look at the REPORTING-BUGS file in the kernel source dir and the
Documentation/BUG-HUNTING file.
Helping to test pre-release kernels is a valuable effort. Run a new kernel
daily :-)
Brian O'Mahoney replied that he agreed with Jesper's advice, with some caveats:
please do NOT debug kernel mods on your 'main-box', where your filesystems
live. unless you like to live dangerously and make perfect backups you
don't mind spending lots of hours restoring,
unless you want to specialise in file systems, but maybe do want to work on
device drivers use a ---
sacrifical system, and, for example NFS mount everything, on it from your
main box, otherwise use a cheap local disk just for your fs stuff
then when you blow it there is no FS damage and you don't need to wait for
FSCK, or Journal Replay, when your fs works you can live more dangerously ;
-)
You will also need a main system, and serial X-over cable, if you want to
use some of the increasing number of tools,
kdb, kgdb, kprobes .... that assume a 2 box setup
Finally, Linus personally dislikes debuggers, ... 'read the source Luke' so
patches to the mm or mainstream should be grounded an source code analysis,
not it works or xxx has 0x1234 in it.
Jesper agreed that "A sacrificial box or at least proper backups of any
important stuff is important. I didn't write that since I figured it to be
obvious, but I guess I should have spelled it out anyway. Thank you for making
that bit clear :-)"
7. DevFS Author Speaks In Favor Of DevFS After Long Silence
18 Jul (4 posts) Archive Link: "Re: [GIT PATCH] Remove devfs from 2.6.12-git"
Topics: BSD: FreeBSD, FS: devfs, FS: sysfs
People: Richard Gooch, Jan Engelhardt, Jim Crilly, Alexander Viro, Daniel
Phillips, Greg KH
With all the discussion of removing DevFS from the kernel, its original author
Richard Gooch made a brief appearance, the first in years. He responded very
briefly to several of Greg KH's recent statements, but didn't stick around for
an argument.
Greg had said that Richard had stated that udev was a proper replacement for
DevFS. Richard replied, "Well, that's news to me!"
Greg had also said that DevFS should be taken out because policy should exist
in userspace and not in the kernel. Richard pointed out that SysFS, developed
in large part by Greg, also implemented policy in the kernel.
To Greg's assertion that DevFS represented clutter and mess, Richard said this
was really in the eye of the beholder.
And to Greg's statement that DevFS was broken and unfixable, Richard simply
said, "No proof. Never say never..."
Jan Engelhardt asked where Richard had been all this time, if he expected DevFS
to be maintained and kept in the kernel. Daniel Phillips replied that Alexander
Viro had chased him out with relentless attacks.
Jan also said in his email, "Something's wondering me, though: FreeBSD "just"
(5.0) introduced devfs, so either they are behind The Facts (see udev FAQ), or
devfs (anylinux/anybsd) is not so bad after all." Jim Crilly replied, "There's
not much to wonder about here, the basic idea of devfs is a good one which is
why udev was written. The problems expressed on lkml about devfs were with that
specifically implementation, if a better implementation had been merged
originally udev might have never been created. I really doubt FreeBSD took the
Linux devfs code and integrated it with their kernel, so the fact that FreeBSD
is using a devfs now simply means they like the idea of a dynamic /dev as
well."
8. New patchview Script For Better Review
20 Jul (1 post) Archive Link: "[announce] 'patchview' ver. 002"
People: Randy Dunlap
Randy Dunlap said:
'patchview' merges a patch file and a source tree to a set of temporary
modified files. This enables better patch (re)viewing and more viewable
context. (hopefully)
The patchview script is here: http://www.xenotime.net/linux/scripts/
patchview
usage: patchview [-f] patchfile srctree {ver. 002}
-f : force tkdiff even if 'patch' has errors
-s : single tkdiff even if patchfile contains multiple files
It uses (requires) lsdiff (from patchutils) and tkdiff.
patchutils: http://cyberelk.net/tim/patchutils/
tkdiff: http://sourceforge.net/projects/tkdiff/
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor
Greg Benson and Professor Allan Cruse in the Department of Computer Science at
the University of San Francisco. This is the same department that invented
FlashMob Computing. Kernel Traffic is hosted by the generous folks at
kernel.org. All pages on this site are copyright their original authors, and
distributed under the terms of the GNU General Public License, version 2.0.