Kernel Traffic #327 by Zack Brown
[email protected] Mon, 12 Sep 2005 16:34:16 -0700
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <[email protected]> |
Kernel Traffic #327 For 12 Sep
By Zack Brown
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Mailing List Stats For This Week
* Threads Covered
1. 28 Aug - 3 Sep (42 Linux 2.6.13 Released; New Policies For
posts) Speeding Kernel Releases
2. 30 Aug - 2 Sep (44 Controversial Article On The Status Of Linux
posts) Graphics
3. 30 Aug - 7 Sep (21 Marvell SATA Support
posts)
4. 30 Aug - 2 Sep (10 Telecom Clock Driver For MPCBL0010 Single
posts) Board Computer
5. 31 Aug - 7 Sep (10 Removing Deprecated Functions; Call For
posts) Maintainers To Update Drivers
6. 1 Sep - 6 Sep (66 Linux 2.6.13-mm1 Released
posts)
7. 1 Sep - 2 Sep (7 Reviving Some Swap Prefetch Patches
posts)
8. 1 Sep (3 Cleaning Out Remaining References To DriverFS
posts)
9. 2 Sep - 3 Sep (12 Status Of Merging FUSE Into The Official Tree
posts)
10. 4 Sep - 6 Sep (17 Support For The Omnikey CardMan 4040 PCMCIA
posts) Smartcard Reader
11. 4 Sep (1 New forcedeth Backport To 2.4 Series
post)
12. 5 Sep - 6 Sep (6 Support For The Omnikey CardMan 4000 PCMCIA
posts) Smartcard Reader
13. 8 Sep (15 Developer Toe-Stepping Over Patch Submission
posts) Policies
14. 8 Sep (1 Reminder Of New Policies For Speeding Up The
post) Release Cycle
Mailing List Stats For This Week
We looked at 1693 posts in 11MB.
There were 686 different contributors. 269 posted more than once. The average
length of each message was 127 lines.
+-----------------------------------------------------------------------------+
| The top posters of the week | The top subjects of the week were: |
| were: | |
|--------------------------------+--------------------------------------------|
|60 posts in 459KB by johannes |44 posts in 220KB for "state of linux |
|stezenbach |graphics" |
|56 posts in 234KB by andrew |42 posts in 180KB for "2.6.13-mm1" |
|morton |38 posts in 228KB for "where is the |
|36 posts in 132KB by |performance bottleneck?" |
|[email protected] |25 posts in 113KB for "ide hpa" |
|34 posts in 121KB by alan cox |20 posts in 135KB for "2.6.13-mm1: hangs |
|30 posts in 121KB by russell |during boot ..." |
|king | |
+-----------------------------------------------------------------------------+
Full Statistics generated by mboxstats version 2.8
1. Linux 2.6.13 Released; New Policies For Speeding Kernel Releases
28 Aug - 3 Sep (42 posts) Archive Link: "Linux 2.6.13"
Topics: Kernel Release Announcement, PCI
People: Linus Torvalds, Jerome Pinot, Thomas Gleixner, Maciej W. Rozycki, Tony
Luck, Keith Owens, Jesper Juhl
Linus Torvalds announced Linux 2.6.13, saying:
There it is.
The most painful part of 2.6.13 is likely to be the fact that we made x86
use the generic PCI bus setup code for assigning unassigned resources. That
uncovered rather a lot of nasty small details, but should also mean that a
lot of laptops in particular should be able to discover PCI devices behind
bridges that the BIOS hasn't set up.
We've hopefully fixed up all the problems that the longish -rc series
showed, and it shouldn't be that painful, but if you have device problems,
please make a report that at a minimum contains the unified diff of the
output of "lspci -vvx" running on 2.6.12 vs 2.6.13. That might give us some
clues.
The changes since -rc7 are pretty small, full shortlog and diffstat of that
appended.
As to the new world order: I'm actually going to be away for most of next
week, but in general we should now try to do all major merges within the
first two weeks of the release. After that, we go into calm-down mode, and
if you have work that didn't make the cut, you get to wait until 2.6.14.
The plan is that this should bring in the time between releases, so that
even stuff that misses the deadline won't have to wait _too_ long for the
next one.
Jesper Juhl said that the ChangeLog only covered patches since -rc7; and asked
if the full 2.6.12-t-2.6.13 ChangeLog could also be posted. Linus replied:
Done.
(Well, it's going to take a while to mirror out).
That's 2.3MB of logs (even the shortlog weighs in at 5000+ lines and 201kB,
if anybody cares. I didn't upload that, and the kernel mailing list limits
don't allow me to put it here, but git users can do
git-rev-list --pretty=short v2.6.12..v2.6.13 | git-shortlog
to generate it. You might additionally want to add a "--no-merges" if you
don't want to see people doing non-linear merges).
Jerome Pinot also suggested:
Using git in the linus tree:
$ git-whatchanged v2.6.12..v2.6.13 --pretty=full
You can get this:
ftp://ngc891.blogdns.net/pub/linux/misc/ChangeLog-2.6.12-2.6.13.txt
Be warn, it's about 3.7MB
And Linus, ever eager to evangelize git, replied:
It's really much nicer to just do
git log --no-merges v2.6.12..v2.6.13
which gives you a much more readable result.
git-whatchanged is useful if you also want to see the files that got
changed (especially with the "-p" flag to see the whole diff), or if you
want to limit it to a specific subsystem ("git-whatchanged drivers/usb"),
but if you just want the log, use "git log".
That "--pretty=full" this gives you committer information (and you can do
it for "git log" too), but most people probably don't care. In fact, you'd
more often find yourself using "--pretty=short", which only shows the first
line ("head-line" - the subject line of an email patch) of the commit
message.
Additionally, you can pipe the output of "git log" to "git-shortlog", and
you'll get the shortlog format (ie head-line only, and sorted by author).
Sadly, some commits ended up missing out on the author field (hey, people
were getting started with git), so you have two commits like this:
commit af25e94d4dcfb9608846242fabdd4e6014e5c9f0
Author: <>
Commit: Tony Luck <[email protected]>
[IA64] Make ia64 die() preempt safe
Signed-off-by: Keith Owens <[email protected]>
Signed-off-by: Tony Luck <[email protected]>
commit af2c80e926ad5335d00a8d507928aff4e8ff1877
Author: ? <?>
Commit: Thomas Gleixner <[email protected]>
[MTD] ms02-nv: Fix 64bit operation
Replace KSEG1ADDR() with CKSEG1ADDR() as the former does not work for
64-bit configurations anymore.
Signed-off-by: Maciej W. Rozycki <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
where the author does show up thanks to the sign-off lines, but the git
author information was left empty, so the git-shortlog thing has two
unattributed changes ;^p
2. Controversial Article On The Status Of Linux Graphics
30 Aug - 2 Sep (44 posts) Archive Link: "State of Linux graphics"
Topics: Framebuffer
People: Jon Smirl, Daniel Stone
Jon Smirl said:
I've written an article that surveys the current State of Linux graphics
and proposes a possible path forward. This is a long article containing a
lot of detailed technical information as a guide to future developers. Skip
over the detailed parts if they aren't relevant to your area of work.
http://www.freedesktop.org/~jonsmirl/graphics.html
Topics include the current X server, framebuffer, Xgl, graphics drivers,
multiuser support, using the GPU, and a new server design. Hopefully it
will help you fill in the pieces and build an overall picture of the
graphics landscape.
The article has been reviewed but if it still contains technical errors
please let me know. Opinions on the content are also appreciated.
Amid various arguments inspired by this post, Daniel Stone, the administrator
of the freedesktop.org server, shut down Jon's account, and they argued about
it. Jon said that Daniel had "taken it upon himself to censor my article on the
state of the X server. His lame excuse is that I have stopped working the core
of Xegl. It doesn't seem to matter that I contributed 1,000s of lines of code
to fd.o that I am continuing to do maintenance on." Daniel, via private email,
argued that "I have done several cleanups now on inactive accounts and
projects. You are absolutely not the first, and will not be the last. I have
not done such sweeps for a while, because I have not had time. The realisation
that your account was doing nothing other than hosting an HTML page now that I
have some amount of time to look at fd.o again was enough to spur me to start a
cleanup, and indeed, I am in the process of pinging many other dormant
contributors." After some behind-the-scenes discussion, Daniel apparently
thought better of his decision, and reinstated Jon's account, and his article.
3. Marvell SATA Support
30 Aug - 7 Sep (21 posts) Archive Link: "[RFC][PATCH 2.6.13] Marvell SATA
support (PIO mode)"
Topics: Serial ATA
People: Brett Russ, Jeff Garzik, Bogdan Costescu, Christoph Hellwig
Brett Russ said, "This is the first public release of my libata compatible low
level driver for the Marvell SATA family. Currently it successfully runs in PIO
mode on a 6081 chip. EDMA support is in the works and should be done shortly.
Review, testing (especially on other flavors of Marvell), comments welcome."
Jeff Garzik liked the code and wanted to get it into the official kernel as
soon as possible. Brett was amendable to this, and posted an updated patch,
with a proper changelog entry and Signed-Off-By header. Christoph Hellwig had
some technical objections, but when Jeff said he intended to push the patches
in spite of those objections, Christoph also accused him of asserting too much
authority. Jeff replied, "Until you're willing to step up and help with 2.4.x
maintenance, you're just being an impediment for non-technical reasons. If you
want to do that, join politics and become a politician. I have real work to
do."
Elsewhere, Brett posted another update to his patch (and Bogdan Costescu said,
"thanks! I've been waiting for such a driver to appear" ). Jeff applied the
patch, and technical discussion continued.
4. Telecom Clock Driver For MPCBL0010 Single Board Computer
30 Aug - 2 Sep (10 posts) Archive Link: "Telecom Clock driver for MPCBL0010
ATCA compute blade."
People: Mark Gross, Marcelo Tosatti, Jesper Juhl
Mark Gross said:
The following is a driver I would like to see included in the base kernel.
It allows OS controll of a device that synchronizes signaling hardware
across a ATCA chassis.
The telecom clock hardware doesn't interact much with the operating system,
and is controlled via registers in the FPGA on the hardware. It is hardware
that is unique to this computer.
Marcelo Tosatti pointed out that Mark's code did not conform to the
Documentation/CodingStyle guidelines; and Mark posted a corrected version of
the patch. Jesper Juhl offered some technical comments as well, and Mark
submitted another updated version before the thread petered out.
5. Removing Deprecated Functions; Call For Maintainers To Update Drivers
31 Aug - 7 Sep (10 posts) Archive Link: "[FINAL WARNING] Removal of
deprecated serial functions - please update your drivers NOW"
Topics: MAINTAINERS File
People: Russell King, Alan Cox, Max Asbock
Russell King said:
As per the feature-removal.txt file, I will be removing the following
functions shortly:
+ register_serial
+ unregister_serial
+ uart_register_port
+ uart_unregister_port
However, there are still some drivers which use these functions:
drivers/char/mwave/mwavedd.c: return register_serial(&serial);
drivers/char/mwave/mwavedd.c: unregister_serial(pDrvData->sLine);
drivers/misc/ibmasm/uart.c: sp->serial_line = register_serial(&serial);
drivers/misc/ibmasm/uart.c: unregister_serial(sp->serial_line);
drivers/net/ioc3-eth.c: register_serial(&req);
drivers/net/ioc3-eth.c: register_serial(&req);
drivers/serial/serial_txx9.c: line = uart_register_port(&serial_txx9_reg, &port);
drivers/serial/serial_txx9.c: uart_unregister_port(&serial_txx9_reg, line);
These drivers really really really need fixing in the next few days if they
aren't going to break. I hereby ask that the maintainers of the above
drivers show some willingness to update their drivers.
Unfortunately, it appears that some of these drivers do not contain email
addresses for their maintainers, neither are they listed in the MAINTAINERS
file. (mwavedd and serial_txx9).
Please note that this is the last warning folk will have before the
functions are removed.
In addition, the following drivers declare functions of the same name. The
maintainers of these need to look to see why, and eliminate them where
possible.
drivers/serial/crisv10.c:register_serial(struct serial_struct *req)
drivers/serial/crisv10.c:void unregister_serial(int line)
Alan Cox replied:
I'll have a quick look at mwave. If I remember rightly it just needs to
tell someone that an "ISA" 16450 serial port materialised by magic at the
addresses it selected.
The mwave firmware is loaded into a DSP and until its loaded there isn't a
serial port
Russell said:
I think that it shouldn't be too big a problem - maybe just using
serial8250_register_port() and serial8250_unregister_port() instead of
register_serial()/unregister_serial(), and changing the structure.
The key thing is that port.dev should be set appropriately and the relevant
calls to serial8250_suspend_port/serial8250_resume_port be made (or
port.dev should be NULL if no power management is expected - in which case
it may be managed as a generic platform port.)
Also, port.uartclk must be set, and since this is an add-in card, it should
not be using BASE_BAUD but the clock rate for the UART on the card itself.
(BASE_BAUD being an architecture defined constant has no business being
used in connection with add-in cards with on-board UART clock generators.)
Alan replied, "Thanks. Thats all I needed to know to whack that into shape once
I've put a legacy 32bit build environment back together for this and for
something akpm wants me to fix in another diff. Power management is umm
special. The port will die on suspend/resume via Linux (via APM seems to be ok)
and need a userspace firmware reload to come back." He posted an MWave patch
shortly thereafter.
Elsewhere, Max Asbock posted a patch to fix up the ibmasm driver.
6. Linux 2.6.13-mm1 Released
1 Sep - 6 Sep (66 posts) Archive Link: "2.6.13-mm1"
Topics: Kernel Release Announcement
People: Andrew Morton
Andrew Morton announced Linux 2.6.13-mm1, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/
2.6.13-mm1/
+ Included Alan's big tty layer buffering rewrite. This breaks the build
on lots of more obscure character device drivers. Patches welcome
(please cc Alan).
7. Reviving Some Swap Prefetch Patches
1 Sep - 2 Sep (7 posts) Archive Link: "[PATCH][RFC] vm: swap prefetch"
People: Con Kolivas
Con Kolivas said:
Here is a working swap prefetching patch for 2.6.13. I have resuscitated
and rewritten some early prefetch code Thomas Schlichter did in late 2.5 to
create a configurable kernel thread that reads in swap from ram in reverse
order it was written out. It does this once kswapd has been idle for a
minute (implying no current vm stress). This patch attached below is a
rollup of two patches the current versions of which are here:
http://ck.kolivas.org/patches/swap-prefetch/
These add an exclusive_timer function, and the patch that does the swap
prefetching. I'm posting this rollup to lkml to see what the interest is in
this feature, and for people to test it if they desire. I'm planning on
including it in the next -ck but wanted to gauge general user opinion for
mainline. Note that swapped in pages are kept on backing store (swap),
meaning no further I/O is required if the page needs to swap back out.
Thomas Schlichter was very happy to see this work being done, and promised to
test Con's patches, not having the time lately to continue developing the
feature himself. Hans Kristian Rosbach was also very interested in this
functionality, and he and Con discussed some possible variants.
8. Cleaning Out Remaining References To DriverFS
1 Sep (3 posts) Archive Link: "[PATCH 0/2] driverfs is dead"
Topics: FS: driverfs, FS: sysfs
Rolf Eike Beer posted some cleanup patches, to remove all references to
DriverFS, which had been renamed to SysFS quite a long time before.
9. Status Of Merging FUSE Into The Official Tree
2 Sep - 3 Sep (12 posts) Archive Link: "FUSE merging?"
People: Miklos Szeredi, Andrew Morton
Miklos Szeredi asked Andrew Morton what the plans were for merging FUSE into
the mainline kernel. He said:
I know you have some doubts about usefulness, etc. Here are a couple of
facts, that I hope show that Linux should benefit from having FUSE:
+ total number of downloads from SF: ~25000
+ number of downloads of last release (during 3 months): ~7000
+ number of distros carrying official packages: 2 (debian, gentoo)
+ number of publicly available filesystems known: 27
+ of which at least 2 are carried by debian (and maybe others)
+ number of language bindings: 7 (native: C, java, python, perl, C#, sh,
TCL)
+ biggest known commercial user: ~110TB exported, total bandwidth: 1.5TB/
s
+ mailing list traffic 100-200 messages/month
+ have been in -mm since 2005 january
Andrew said he hadn't thought about FUSE much in the recent past, but that:
I agree that lots of people would like the functionality. I regret that
although it appears that v9fs could provide it, there seems to be no
interest in working on that.
The main sticking point with FUSE remains the permission tricks around
fuse_allow_task(). AFAIK it remains the case that nobody has come up with
any better idea, so I'm inclined to merge the thing.
Joshua J. Berry and Kasper Sandberg both spoke in favor of FUSE, saying they
had been using it happily for some time.
Miklos told Andrew he'd go to the Moon to get this thing merged, or at least to
a new re-split of the patches, but Andrew said this wouldn't be necessary. He
said, "at this stage, objections would need to be substantial, IMO. We're
rather deadlocked on the permission thing, but if we can't come up with
anything better then I'm inclined to say what-the-hell." Miklos was pleased
with this plan.
10. Support For The Omnikey CardMan 4040 PCMCIA Smartcard Reader
4 Sep - 6 Sep (17 posts) Archive Link: "[PATCH] New: Omnikey CardMan 4040
PCMCIA Driver"
Topics: BSD
People: Harald Welte
Harald Welte said:
Below you can find a driver for the Omnikey CardMan 4040 PCMCIA Smartcard
Reader.
It's based on some source code originally made available by the vendor (as
BSD/GPL dual licensed code), but has undergone significant changes to make
it more compliant with the general kernel community coding practise.
As this is the first PCMCIA driver that I'm involved in, please let me know
if I missed something.
If there are no objections, I'd like to see it included in mainline.
Thanks!
There were no direct objections, but several folks had suggestions for
improvements, and Harald updated his patch in response.
11. New forcedeth Backport To 2.4 Series
4 Sep (1 post) Archive Link: "[CFT] forcedeth backport to 2.4"
People: Manfred Spraul
Manfred Spraul said:
Attached is a backport of the latest forcedeth version to 2.4. It includes
lots of changes, among them:
+ a critical bugfix for nv_open(): ifdown/ifup cycles resulted in an
incomplete initialization that causes hangs after a few MB network
traffic.
+ jumbo frame support
+ far better ethtool support
+ 64-bit dma support
+ support for additional nforce versions.
It compiles and boots, but I can't test it properly. Could you give it a
try?
There was no reply on the list.
12. Support For The Omnikey CardMan 4000 PCMCIA Smartcard Reader
5 Sep - 6 Sep (6 posts) Archive Link: "[PATCH] Omnikey Cardman 4000 driver"
People: Harald Welte, Jesper Juhl
Harald Welte said:
Following-up to the Cardman 4040 driver, I'm now sumitting a driver for the
Cardman 4000 reader. It is, too, a PCMCIA smartcard reader and the
predecessor of the 4040.
From a technical point of view, the two devices have nothing in common, so
there is no possibility of code sharing.
Please consider mergin mainline, thanks.
Note: The patch is incremental to the Cardman 4040 driver that has already
been submitted.
Jesper Juhl remarked, "Wouldn't it be better to first merge it in -mm and get
some wider testing before pushing for mainline?" And Harald replied:
From my past experience (I'm involved in writing smartcard reader drivers
for some time now), users of smartcard readers tend to be "typical
corporate users" who won't run anything but the distribution kernel.
I really doubt that the drivers would get much more testing in -mm than
they would in mainline.
Also, what is the point of putting entirely new code (no changes to
existing code!) into -mm? I understand that changes to existing code can
inarguably benefit from some testing in -mm first.
But new drivers? Where's the point? The devices are not supported in the
existing kernel, so it cannot get worse by having a driver (even if it
still contains one or the other bug).
There was no discussion about this, and the thread ended immediately. Harald
did post an update to his patch.
13. Developer Toe-Stepping Over Patch Submission Policies
8 Sep (15 posts) Archive Link: "Serial maintainership"
Topics: MAINTAINERS File
People: Russell King, Alan Cox, Linus Torvalds, David S. Miller, Alexander Viro
Russell King said:
I notice DaveM's taken over serial maintainership. Please arrange for
serial patches to be sent to davem in future, thanks. (All ARM serial
drivers are broken as of Tuesday.)
I might take a different view if I at least had a curtious CC: of the
patch, which I had already asked akpm to reject.
Thanks. That's another subsystem I don't have to care about anymore.
Alan Cox remarked, "Please remember to send Linus a patch updating MAINTAINERS
if so." Linus Torvalds stepped in, saying:
Guys, stop being stupid about things. I already sent rmk an email in
private. And Alan, there's absolutely no point in making things even worse.
Mistakes happen, and the way you fix them is not to pull a tantrum, but
tell people that they are idiots and they broke something, and get them to
fix it instead.
You don't have to be polite about it, and swearing is fine. So instead of
saying "I don't want to play any more because Davem made a mistake", say
something like "Davem is a f*cking clueless moron, here's what he did and
here's why it's wrong".
Notice? In both cases you get to vent your unhappiness. In the second case,
you make the person who made a mistake look bad. But in the first case,
it's just yourself that looks bad.
David S. Miller took the opportunity to defend the patch in question, saying,
"Even as networking maintainer, other people put changes into the networking as
build or warning fixes, and I have to live with that. If I don't like what
happened, I call it out and send in a more appropriate fix. This is never
something worth peeing my pants in public about." He said his patch had fixed a
real problem, and he didn't see anything wrong with that. He, Russell, and
Linus (with a little help from Alexander Viro) hashed out the technical merits
of David's patch, with the conclusion being that in fact, the patch needed to
be reverted, or at least have a small addition layered on top; David and Linus
worked out those final details.
14. Reminder Of New Policies For Speeding Up The Release Cycle
8 Sep (1 post) Archive Link: "Reminder: 2.6.14 merge window closing"
People: Linus Torvalds
Linus Torvalds said:
As per the new merge policies that were discussed during LKS in Ottawa
earlier during the summer, I'm going to accept new stuff for 2.6.14 only
during the first two weeks after 2.6.13 was released.
That release was ten days ago, so you've got four more days before I don't
want any big merges.
After that, I'll do a -rc1, and then we're supposed to just do fixes and
thus only work on any regressions and other immediate issues.
I've been merging a lot lately (happily, I got some work done during the
trip last week), so we certainly already have enough for 2.6.14. But I just
wanted to remind people that if they expected me to merge your work, you're
getting closer to the cut-off point..
(Of course, if you already sent me a pointer, and I haven't merged it yet,
it might be because I missed something during travels, so please do re-send
in that case)
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.