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

Kernel Traffic #302 For 2 Apr 2005

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 2428 posts in 15MB. See the Full Statistics.

There were 720 different contributors. 285 posted more than once. The average length of each message was 125 lines.

The top posters of the week were: The top subjects of the week were:
149 posts in 751KB by Andrew Morton
136 posts in 763KB by Greg KH
87 posts in 554KB by Adrian Bunk
74 posts in 392KB by Domen Puncer
61 posts in 455KB by Jeff Garzik
54 posts in 197KB for "Linux"
48 posts in 223KB for "[PATCH/RFC] I/O-check interface for driver's error handling"
48 posts in 217KB for "[ACPI] Call for help: list of machines with working S3"
33 posts in 223KB for "Page fault scalability patch V18: Drop first acquisition of ptl"
28 posts in 112KB for "[Alsa-devel] Re: intel 8x0 went silent in 2.6.11"

These stats generated by mboxstats version 2.2

1. Linux 2.6.11-rc4-mm1 Released

23 Feb 2005 - 3 Mar 2005 (81 posts) Archive Link: "2.6.11-rc4-mm1"

Topics: Kernel Release Announcement

People: Andrew Morton

Andrew Morton announced Linux 2.6.11-rc4-mm1, saying:

2. Support For GEODE CPUs in 2.6

27 Feb 2005 - 3 Mar 2005 (4 posts) Archive Link: "Support for GEODE CPU's in Kernel 2.6.10."

Topics: Small Systems

People: Kianusch Sayah Karadji

Kianusch Sayah Karadji said:

This is a small patch for GEODE CPU support in Kernel 2.6.10.

Those CPU's are found mostly in embedded systems ... one of the most prominent Hardware using GEODE CPU is probably soekris net4801 (

This patch has been on my homepage ( for quite a time - but I've been asked several time to have it included in the main kernel.

3. New Digi Neo Serial Port Adapter Driver

27 Feb 2005 - 4 Mar 2005 (7 posts) Archive Link: "[ patch 1/7] drivers/serial/jsm: new serial device driver"

Topics: PCI

People: Wen XiongChristoph HellwigJeff GarzikGreg KH

Wen Xiong said:

We are submitting a new serial driver for the 2.6 kernel. This device driver is for the Digi Neo serial port adapter.

We made some changes based on great comments from linux community. We used the Russell's serial_core interface on 2.6 kernel, handled all initialization of module correctly and used fs/seq_file.c interface for /proc entry. And we made some changes based on Greg KH's comments also including removing whitespace, changing some function comments, removing msleep() etc.

Per requests, I split it up in smaller chunks and sent them in several emails for you. You are able to read the code and comment the code easily. I added more adapter descriptions for you.

Neo adapter description:

This adapter is a 920K baud non-intelligent asynchronous serial communications adapter for PCI bus. The adapter is based on Exar 17D152 Universal PCI Dual UART IC. The adapter is mapped into the PCI bus memory space, and offers extened UART register mapping beyond the standard 16c554 registers. This driver used serial_core.c interface on 2.6 serials of kernel.

Jeff Garzik felt the patch had altogether too many global variables; and other folks had criticisms too. Wen took all this into consideration, and several days later replied:

Based on very detail comments from Jeff, Greg, Christoph Hellwig, Rik and Nish, I modified these codes and tested it succesfully in our lab. For patch1, major changes included:

  1. removed static board limit to use dynamic list to control board structure.
  2. leak on errors.
  3. removed some global variables
  4. lots of others.

Jeff was happy to see the update, and asked Wen to submit the full series of patches for consideration.

4. Status Of Modular Framebuffers

28 Feb 2005 - 5 Mar 2005 (18 posts) Archive Link: "RFC: disallow modular framebuffers"

Topics: Framebuffer, Small Systems

People: Adrian BunkDavid VrabelPaul MundtJeff Garzik

Adrian Bunk asked:

Do modular framebuffers really make sense?

OK, distributions like to make everything modular, but all the framebuffer drivers I've looked at parse driver specific options in their *_setup function only in the non-modular case.

And most framebuffer drivers contain a module_exit function. Is there really any case where this is both reasonable and working?

Jeff Garzik said this was really a case-by-case thing, but David Vrabel said modular framebuffers made sense on embedded systems, where "you may not use the display hardware (and would therefore like to save a bit of memory) but it's convenient to have only one build of the kernel/modules." He also added, "It's useful for testing if nothing else. True, the Geode framebuffer driver won't restore the mode on unload but since the software VGA emulation on a Geode is less than perfect (I never did work out what happened to the cursor...) I would expect people to not use vgacon and thus there's nothing really to restore."

Paul Mundt agreed that embedded systems made good use of modular framebuffers, adding:

It makes little sense to keep the driver constantly loaded if the device is not being used as a console and is only seeing occasional use.

It seems more sensible to just fix up the drivers that don't do this right.. most of the broken drivers seem to be geared at x86 anyways where people generally don't seem to care.

It may not make a lot of sense with distributions on x86, though it is useful if you are doing driver development on a secondary device. This is certainly a corner case though.

5. Linux 2.6.11-rc5-mm1 Released

1 Mar 2005 - 4 Mar 2005 (32 posts) Archive Link: "2.6.11-rc5-mm1"

Topics: Access Control Lists, FS: NFS, Hot-Plugging, Kernel Release Announcement, SMP

People: Andrew Morton

Andrew Morton announced Linux 2.6.11-rc5-mm1, saying:

6. Improving The BitKeeper->CVS Gateway

1 Mar 2005 - 4 Mar 2005 (4 posts) Archive Link: "[BK] cvs export"

Topics: Version Control

People: Larry McVoyStelian PopPavel Machek

Larry McVoy said:

A while back someone complained about the CVS exporter because it sometimes groups a pile of BK changesets into one commit. That's true, it does.

I've been running tests over the BK tree and I think we can do better. Here's the scoop: when we do an export we are going from a very bushy graph structure to a linear graph structure. The BK graph structure represents what happened in all the BK repos that ever came together, the CVS graph structure is more like what would happen if all the work had been done in CVS. What that means in practice is that the linearization sometimes results in a single CVS commit which has multiple changesets in it. Pavel or someone complained that the problem with that is that if you are looking for a bug and you are searching through commits, that works fine *unless* your bug happens to be in one of the commits which is really a pile of changesets. Is that accurate Pavel/Andrea/Roman/etc?

In the last flamefest about BK there was all this fuss that there wasn't enough info in the CVS export and I think that the problem described above is the basis for 99% (or maybe 100%) of the flameage. Is that also accurate?

I tried to point out the following and think it was lost in the noise: while the repository commits themselves construct a very bushy graph, the files are not at all bushy, they are extremely linear. So what does that actually mean? The history of the repository is very parallel, that's what creates a bushy revision history graph, but in spite of that, there is very little parallelism in the actual files. The result of that is that when we do the CVS export, it is true that the number of commits is about half the number of BK commits. But the number of file deltas is only 4% less than the number of file deltas in BK.

Pavel/Andrea/Roman/etc still were unhappy and they are justified in being unhappy because even though we have almost all of the file history what we don't have is all of the patch boundaries. And when you are hunting down a bug, if you look at Documentation/BUG-HUNTING (which I wrote back in 1996 amusingly enough) the idea is to do binary search over a range of changes in order to narrow down the cause.

Which leads us back to the problem. If you narrow things down but where you land is one of the clustered commits which has many changesets in it then you are stuck with having to wade through a big pile of diffs to find the bug, those diffs consisting of multiple patches. Sound right to you Pavel/Andrea/Roman/etc?

If so, I have to agree with you, this is a limitation of the CVS exporter. So I've been thinking about how to fix this and have the following idea. I want all the CVS export users to pay close attention because this either should make you happy or not and I want to know the answer.

When we do the export we do a couple of things to make things pleasant for you. We make sure that the timestamps on all the files in the same commit are the same, that makes timestamp based tools work. We also shove a comment into each file's history that looks like so: (Logical change 1.12345) so that tools that try and group things based on comments can work.

It's that second feature that I think we can use to solve the problem, we're finally getting to the idea. If we have a commit that is really 200 patches which touch 400 files then we can do better. Suppose that the files in the patches are disjoint, i.e., each patch touches a different set of files, there is no overlap. If that's true then we could change the comment to (Logical change 1.12345.$PATCH). It's still all one CVS commit but if you need to go working through that commit to get at the individual patches you could, right?

One problem is that the set of files in patches may not be disjoint, the same file may participate in multiple patches. I think we can handle that in the following way, we put multiple comments, one for each patch, so you'd see

(Logical change 1.12345.5)
(Logical change 1.12345.11)
(Logical change 1.12345.79)

That's not a perfect answer because now that file participates in multiple patches and if it's the one that has the problem you'll have to wade through the diffs for that file for that commit. But that's an extreme corner case as far as I can tell (I have faith I'll be "educated" if I'm wrong about that).

So, everyone including the Pavel/Andrea/Roman/etc camp, how do you feel about this? If we were to hack the exporter to add this info do you think that would address the problems you have with the exporter? The reason I ask is that while I was going to just hack this in, I went to do that and it turned into a nasty problem, both engineering and CPU wise when exporting. So if this isn't what you wanted then I won't bother to do it.

I'm not asking if this is the same as GPLing BK or giving people free access to 100% of the BK internal data structures, etc. What I'm asking is if this will make the CVS export tree something you can use to get your job done in an efficient way.

Stelian Pop replied, "Your proposal adds more information to the CVS export tree and this is good. But as far as I can tell it still doesn't let the user find the original patch for a change (unless you can use the extended logical change information to access the patch somewhere else which would be acceptable to me)." Pavel Machek also agreed Larry's proposal was better than the current situation; but there was no discussion.

7. FUSE Going Into 2.6

2 Mar 2005 - 5 Mar 2005 (12 posts) Archive Link: "[request for inclusion] Filesystem in Userspace "

Topics: Device Mapper, FS: CacheFS, FS: NFS, Profiling

People: Andrew MortonAnton AltaparmakovMiklos SzerediChristoph Hellwig

Miklos Szeredi asked if FUSE could be merged into the main kernel, having spent a significant amount of time in Andrew Morton-s -mm tree. Andrew replied:

I was planning on sending FUSE into Linus in a week or two. That and cpusets are the notable features which are 2.6.12 candidates.

Anton Altaparmakov remarked:

I would certainly vote for FUSE going in. Even if it has some bits that could be improved the code works well. It has been in global use for quite a while. We use it in a production environment on four servers and over 650 workstations to provide a "magic symlink filesystem" (i.e. symlink XYZ points to different place depending on which user looks at it) and we have not experienced any problems. I have also done other testing with a layering fs using fuse and that was very stable (but slower than the symlink approach which is why we went for that).

FUSE may not be perfect but lets face it - which code is? And more importantly a lot of code in the kernel is broken (for at least some people) yet it is in the kernel and FUSE does work well...

Christoph Hellwig wanted some additional time to go over the code; and Miklos was fine with this. It seemed that, sooner or later, FUSE will be accepted into the 2.6 tree.

8. New w.x.y.z Kernel Numbering Scheme Lumbering Forward

3 Mar 2005 - 7 Mar 2005 (37 posts) Archive Link: "[PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec"

Topics: Version Control

People: Greg KHLinus TorvaldsRene RebeChris WrightJeff Garzik

Rene Rebe posted a one-line fix for 2.6.11, and Jeff Garzik said this would be a good candidate for a 2.6.11.y kernel release. Greg KH replied:

Ok, I've fixed up the patch and applied it to a local tree that I've set up to catch these things (it will live at bk:// until Chris Wright and I set up how we are going to handle all of this.)

Feel free to start pointing stuff like this at me and chris (we'll also be setting up an alias for it.)

There was some wrangling over the patch, different versions surfaced, and folks weren't sure which one would be best to apply. Another patch also appeared, for a different problem, and Greg and Chris Wright considered whether to include that in a 2.6.11.y release as well. Greg decided to include the new patch, but now Linus Torvalds objected:

I don't think your process works. You never really gave people the time to object. So for that reason you applied the first trivial raid6 thing, and it turned out to be wrong.

I think the patches need to have a rule like "they live outside the sucker tree for at least two days". And during that time, anybody can vote them down (which would move them to "unapplied" status, at which point somebody else might decide that for _their_ tree it's still the right thing to do).

And if at the end of two days, they still haven't gotten enough "yes" votes, they'd go into "limbo" status, with one extra grace-period (ie a reminder on whatever list about a patch that is dying). And if it can't get enough "yeah, sure" votes even after that, it goes into the same "unapplied" list.

In other words, I think this really does want some automation. It shouldn't be fully automated (at the very least, somebody needs to actually check that things patch and fix up the changeset comments etc), but the _rules_ should be automated. Otherwise they'll always be broken because of "_this_ time it's obvious", which is against the point.

Greg agreed with this, and said, "Ok, Chris and I are going to sit down and work this all out on Tuesday. I'll hold off on applying or releasing anything else until we fully describe the process, and set up the infrastructure."

9. Kernel Crypto API Maintainership

4 Mar 2005 (1 post) Archive Link: "New Kernel Crypto Maintainer"

People: James Morris

James Morris said:

This is to announce that Herbert Xu is now taking over my role as co-maintainer of the kernel crypto API.

I've not been able to devote enough time to the integration of async/hardware support, and Herbert, who has been doing excellent work in the networking code for some time, has now thankfully stepped up to help.

Hopefully things will now move forward more quickly in this area.

10. Linux Released; Some Discussion Of Protocol

4 Mar 2005 - 8 Mar 2005 (54 posts) Archive Link: "Linux"

Topics: Version Control

People: Greg KHIan PilcherLinus TorvaldsAndrew MortonRussell KingChris WrightJeff Garzik

Greg KH said:

For those of you who haven't waded through the huge "RFD: Kernel release numbering" thread on lkml to realize that we are now going to start putting out 2.6.x.y releases, here's the summary:

A few of us $suckers will be trying to maintain a 2.6.x.y set of releases that happen after 2.6.x is released. It will contain only a set of bugfixes and security fixes that meet a strict set of guidelines, as defined by Linus at:

Chris Wright and I are going to start working on doing this work, we will have a <SOME_ALIAS> to post these types of bug fixes to, and a set of people we bounce the patches off of to test for "smells good" validation. We will also have a bk-commits type mailing list for those who want to watch the patches flow in, and a bk tree from which changsets can be pulled from.

Chris and I will be hashing all of the details out next Tuesday, and hopefully all the infrastructure will be in place soon. When that happens, we will post the full details on how all of this is going to work. In the meantime, feel free to CC: me and Chris on patches that everyone thinks should go into the 2.6.11.y releases.

But right now, Chris is on a plane, and we don't have the email alias set up, or the proper permissions set up on to push changes into the v2.6 directory, but we have a few bugs that are needing to be fixed in the 2.6.11 release. And since our mantra is, "release early and often", here's the first release.


I've released the patch:

With a detailed changelog at:

A bitkeeper tree for the 2.6.11.y releases can be found at:

The diffstat and short summary of the fixes are below.

I'll also be replying to this message with a copy of the patch itself, as it is small enough to do so.

A number of kernel folks burst into tears of joy to see this work. Others had more sober comments. Ian Pilcher replied, "From a purely process point of view, my concern would be making sure that everything that goes into 2.6.X.Y (e.g. makes it into 2.6.X+1 (e.g. 2.6.12)." And Greg replied, "It will be so." And somewhere else in the thread, Linus Torvalds said, "I'll just pull from the sucker-tree."

However, this merge question turned out to be a little more complicated than folks might have hoped. Some patches, it was revealed, would be in the w.x.y.z tree, that were not intended for the w.x.y tree at all. Of course it would be possible to revert the unwanted patches during the merge, which would be fine for small stuff; but as Andrew put it, "we end up with a cset in the permanent kernel history which simply should not have been there." Greg was surprised that Linus and Andrew would consider this such a big deal, but Linus confirmed that "Once? No. If it ends up being "par for the course", it's bad."

At one point, Russell King suggested bypassing this problem by having two 'sucker' trees, one with fixes intended for Linus, and another with fixes to keep out of the main tree. Jeff Garzik thought this was a good idea, but Linus said:

However, it's also true that the thing BK is _worst_ at is cherry-picking things, and having a collection of stuff where somebody may end up vetoing one patch and saying "remove that one".

So it's entirely possible that the proper tool to use for the first level is not BK at all, but the evolved patch-scripts that Andrew uses, in other words:

may well be a much better thing to use.

I love BK, but what BK does well is merging and maintaining trees full of good stuff. What BK sucks at is experimental stuff where you don't know whether something should be eventually used or not.

11. Guidelines For Accepting Patches Into The w.x.y.z Tree

4 Mar 2005 - 7 Mar 2005 (23 posts) Archive Link: "[RFQ] Rules for accepting patches into the linux-releases tree"

Topics: Version Control

People: Greg KHDave KleikampValdis KletnieksAdam SampsonAndries BrouwerMarcelo TosattiIan PilcherLinus Torvalds

Greg KH said:

Anything else anyone can think of? Any objections to any of these? I based them off of Linus's original list.

Rules on what kind of patches are accepted, and what ones are not, into the "linux-release" tree.

Ian Pilcher suggested that one rule should be that the patch in question should already be in Linus Torvalds's main tree. But Dave Kleikamp replied, "No, it's cleaner in bitkeeper terms for the patches to be pulled into the linux-releases tree first, and then Linus pulls from that. Linus has said that that is what he intends to do." Valdis Kletnieks also said, "There's a high probability that we hit a bug where Linus commits a more extensive "correct" solution, but 2.6.X.1 includes a much simpler band-aid that's technically bogus, but stops a panic-on-boot bug from manifesting."

Looking at the original list, Adam Sampson asked if "a trivial patch that fixed a data corruption issue wouldn't be accepted?" Greg agreed that this was important, and added data corruption to the list of things that could be fixed by one of these patches.

Elsewhere, Andries Brouwer said:

I would like the requirement: "It must be obviously correct".

In a hundred lines one can put a lot of tricky code and subtle changes. For example, if a security problem necessitates a nontrivial change, it should cause an earlier release of 2.6.x+1 instead of a 2.6.x.y+1.

Greg said he'd add that item to the list. Elsewhere, Marcelo Tosatti also suggested that fixes should be acceptable if they fixed breakage of previously working functionality.

12. Video4Linux Maintainership

8 Mar 2005 (3 posts) Archive Link: "[patch] v4l: MAINTAINERS file update."

People: Gerd KnorrAlan Cox

Gerd Knorr said:

Goodbye, and that thanks for all the fish ;)

After several years of v4l maintainance I'm going to switch to a new work field and will not be able to spend much time on maintaining video4linux and the drivers, so someone else will have to step in.

I will not suddenly disappear from earth, I will be available for questions and patch reviews for some time, but I'll stop doing active development and most likely will not have the time to act as central patch relay for all video4linux stuff.

Alan Cox and others thanked Gerd for all his hard work.

13. Linux 2.4.30-pre3 Released

9 Mar 2005 (3 posts) Archive Link: "Linux 2.4.30-pre3"

Topics: Serial ATA

People: Marcelo Tosatti

Marcelo Tosatti announced Linux 2.4.30-pre3, saying:

Here goes the third pre of v2.4.30.

It contains a small number of scattered fixes, most notably e1000 update, a backport of v2.6's nForce override fix, and SATA update.

The changes which broke "tar --verify" on tapes have been reverted.







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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.