Kernel Traffic
Latest | Archives | People | Topics
Wine
Latest | Archives | People | Topics
GNUe
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
 

Kernel Traffic #327 For 12 Sep 2005

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 1693 posts in 11MB. See the Full Statistics.

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 were: The top subjects of the week were:
60 posts in 459KB by johannes stezenbach
56 posts in 234KB by andrew morton
36 posts in 132KB by [email protected]
34 posts in 121KB by alan cox
30 posts in 121KB by russell king
44 posts in 220KB for "state of linux graphics"
42 posts in 180KB for "2.6.13-mm1"
38 posts in 228KB for "where is the performance bottleneck?"
25 posts in 113KB for "ide hpa"
20 posts in 135KB for "2.6.13-mm1: hangs during boot ..."

These stats generated by mboxstats version 2.8

1. Linux 2.6.13 Released; New Policies For Speeding Kernel Releases

28 Aug 2005 - 3 Sep 2005 (42 posts) Archive Link: "Linux 2.6.13"

Topics: Kernel Release Announcement, PCI

People: Linus TorvaldsJerome PinotThomas GleixnerMaciej W. RozyckiTony LuckKeith OwensJesper 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 2005 - 2 Sep 2005 (44 posts) Archive Link: "State of Linux graphics"

Topics: Framebuffer

People: Jon SmirlDaniel 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 2005 - 7 Sep 2005 (21 posts) Archive Link: "[RFC][PATCH 2.6.13] Marvell SATA support (PIO mode)"

Topics: Serial ATA

People: Brett RussJeff GarzikBogdan CostescuChristoph 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 2005 - 2 Sep 2005 (10 posts) Archive Link: "Telecom Clock driver for MPCBL0010 ATCA compute blade."

People: Mark GrossMarcelo TosattiJesper 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 2005 - 7 Sep 2005 (10 posts) Archive Link: "[FINAL WARNING] Removal of deprecated serial functions - please update your drivers NOW"

Topics: MAINTAINERS File

People: Russell KingAlan CoxMax Asbock

Russell King said:

As per the feature-removal.txt file, I will be removing the following functions shortly:

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 2005 - 6 Sep 2005 (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/

7. Reviving Some Swap Prefetch Patches

1 Sep 2005 - 2 Sep 2005 (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 2005 (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 2005 - 3 Sep 2005 (12 posts) Archive Link: "FUSE merging?"

People: Miklos SzerediAndrew 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:

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 2005 - 6 Sep 2005 (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 2005 (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:

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 2005 - 6 Sep 2005 (6 posts) Archive Link: "[PATCH] Omnikey Cardman 4000 driver"

People: Harald WelteJesper 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 2005 (15 posts) Archive Link: "Serial maintainership"

Topics: MAINTAINERS File

People: Russell KingAlan CoxLinus TorvaldsDavid S. MillerAlexander 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 2005 (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.