Tim Waugh asked, When is a driver supposed to return 0 from a __setup function? When it can't parse the options? Or when there's a possibility that the option is intended for another driver? When no one replied for almost a week, he asked, Is it worth me making a patch to change the behaviour of those drivers that return 0 on error (rather that when the option could be used by another driver) to return 1 instead? Alan Cox replied, I've done some of them but not all. So yes. And seven hours later, Russell King said that Alan had sent him the ARM-specific parts of a patch Tim had presumably sent to Alan. Russell affirmed that it would be going into the Linus tree, and thanked Tim heartily.

Soohoon Lee reported serious data corruption with ext2, in cases of low memory and frequent file creation and deletion operations. He explained that under those conditions, files would spontaneously disappear or be undeletable, the contents of two files would spontaneously switch, and fsck would find inconsistancies in properly unmounted filesystems. He posted a one-line patch to fs/ext2/namei.c to fix it; and Theodore Y. Ts'o confirmed that this was indeed a problem, and not just some local glitch. In response to Soohoon's patch, Ted replied, This apparently solves the problem for Linux 2.2, but I'd prefer a cleaner patch for Linux 2.3. Enclosed find the patch, which I will be sending on to Linus. I haven't had a chance to backport this patch to Linux 2.2 yet, but it shoudl be relatively simple. He posted his patch, which was much longer than Soohoon's, and there was some talk about other changes to make to fs/ext2/namei.c, if they were going to be changing it at all.

After a bit of private discussion between Jean-Luc Pedneault, Justin Guyett, Urban Widmark, and other unknown assailants; Urban posted a patch for a problem Jean-Luc had been having with via-rhine under 2.3.99-pre3. But he acknowledged being mystified over why a value that was just written is no longer there, except if you add an if or printk then the value written "stays" written. Jean-Luc replied, Like you said, it seems that by doing the "if" instruction, the old value doesn't get wiped. The inside loop doesn't ever get run!! It's weird, because it may suggest that the system runs too fast or something.. like if the value wasn't written in memory. He added, It could be a bug in GCC 2.95.2, a bug that does an optimization wrongly. I'm using this compiler. I haven't tested with egcs-1.1.2 yet (and I don't have GCC 2.7.2.3 compiled at all).

A couple of hours later, he went on to say, I'd like to point out that egcs-1.1.2 executed the code fine even with #if 0 (ie. without compiling the additional code). GCC 2.95.2's optimizations breaks the code, at least that's what I think. Urban agreed, but rather than attempt to understand the inscrutable assembly code generated, he posted another patch which tried to do the same thing in a different way. He also suggested generating a smaller, non-kernel test-case to share with the GCC developers, and offered to do it himself if no one else stepped forward. Stephane Casset replied with confirmation that Urban's patch seemed to work.

In the end, Urban concluded the thread by pointing out that the latest GCC snapshot appeared not to have the problem anymore, and he also gave a link to Code Sourcery, a really cool page that would compile any code on the latest snapshot.

An interesting threadlet came out of this interesting discussion about Linux implementation of POSIX threading. In the course of discussion, Ulrich Drepper led into it by saying, some additional functionality required to implement the correct POSIX threads behaviour is missing. Alvin Starr let himself in for it when he replied, I am sure that if the next version of the thread library required a set of kernel patches to run effectivly then those patches would end up in the kernel source tree within a version or so. Richard Gooch replied, Mate, where have you been? The day Linus lets user-space dictate what goes into the kernel is the day hell freezes over. If you want a patch to go into the kernel, you need to convince him it's a good idea. Adding a dependency in user-space, expecting it to "force his hand", will not help. It will probably just piss him off. Or make him laugh.

A bit later, Linus Torvalds made a case about PID sharing and gave some example code. He went on to say, about threading:

A post or so down the line, Linus added

Some earlier discussion of clone() took place in ; a LinuxThreads announcement appeared in ; a little bit of clone() history appeared in ; some general discussion of threading took place in ; then in , Alan Cox said CLONE_PID would be going away in 2.3.x, but according to Linus' statements above, this has not happened yet. A vfork() flamewar (with some good technical goodies) took place in .

Discussions of development philosophy occur throughout KT, but some specific articles are , , , , and .

Mike A. Harris had a problem with his keyboard repeat rate slowing down when switching a shared keyboard between two machines. In the course of discussion, it came out that if there was any loss of power to the keyboard, this would be the inevitable result. However, at some point Andrew Morton mentioned:

Russell replied, I'll be sorting it out later today when I do my next set of patches for Linus et al.

Rik van Riel posted a patch against 2.3.99pre3, to take some code out from the interior of a while loop in kswapd; and added, I wonder who sent the brown-paper-bag patch with the superfluous while loop to Linus ... Kanoj Sarcar replied red handed, That would be me ... He asked what Rik's patch actually fixed, aside from the while loop, which appeared cosmetic. Rik replied that ditching the loop was actually a serious fix by itself. Without his patch, he reported that kswapd used between 50% and 70% of the CPU in a particular workload. With his patch, it used between 3% and 5% of the CPU. Kanoj pointed out that the while loop had been in the kernel since way back in 2.3.43, and Linus Torvalds, replying elsewhere, said, you're definitely right that this is not a new bug introduced by you, Kanoj - this seems to be just a thinko that has been there for a long long time. And I suspect I may have been the original perpetrator of the crime. Kanoj let out a facetious sigh of relief that he hadn't introduced the bug, and they discussed some of the ins and outs of Rik's patch. It turned out that, as Linus described the situation prior to Rik's patch:

Elsewhere, under the Subject: [RFT] balancing patch, Kanoj posted a separate patch to ease kswapd's CPU usage. Mark Hahn didn't notice any improvement, and Christoph Rohland noticed various Out Of Memory breakages when the system started to use swap. However, Rik reported:

Alan Cox posted his latest list of things to do before 2.4 could come out:

Wakko Warner replied to item 4.13 (PCMCIA/Cardbus hangs, IRQ problems, Keyboard/mouse problem (may be fixed ?)), with, Fixed for me. Since yenta doesn't probe irq12, it doesn't cause me any lockups.

There were some other scattered comments as well, but nothing conclusive.

Alan Cox announced a patch against 2.3.99pre3, so people could keep up with him in their debugging expeditions, but Arjan van de Ven noticed that it wasn't on any of the kernel.org mirrors. Alan replied, It does appear not to be mirroring right. I've put a copy on ftp.linux.org.uk:/pub/linux/alan/. H. Peter Anvin offered, Please report broken kernel.org mirrors **including IP address** to ftpadmin@kernel.org as soon as you can tell, please. James H. Cloos Jr. also explained:

Rik van Riel posted a patch against 2.3.99, to implement a low overhead fair process scheduler. As he explained in the code comments, It works by handing out CPU time like we do at the normal recalculation. The catch is that we move the list head (where the for_each_task() loop starts) to _after_ the first task where we ran out of quota. This means that if a user has too many runnable processes, his tasks will get extra CPU time here in turns. But he reported to the list:

Jun Sun gave his tentative opinion, Interrupt handlers sometimes call kernel functions that would require a lock on tasklist_lock. If that interrupt happens during the time you hold write lock on tasklist_lock, a deadlock would happen. He suggested using write_lock_irq() to fix it, and added, BTW, I really think interrupt handlers acquiring the same locks which can be acquired by processes is a *BIG* problem in Linux. Andrew Morton asked why Jun though this, and Jun replied, Linus told me so. I believe him. :-) On a more technical note, he added, I did sniff around the source code and spotted a couple of places where locks COULD be acquired by ISRs, but I never did a RUN-TIME check to catch this situation, and went on to say:

There was no reply to this, but Rik, replying to Jun's suggested write_lock_irq(), posted a new patch, and said:

That was it.

George Bonser noticed in the ip-route cref document, a description of the 'equalize' modifier: "allow packet by packet randomization on multipath routes. Without this modifier route will be frozen to one selected nexthop, so that load splitting will occur only on per-flow base." The same document said that the kernel had to be patched to make use of this feature. George asked if this was still the case, or if 'equalize' had been integrated into the main kernel sources. Andi Kleen and Guus Sliepen (author of the patch) replied that it had not been integrated. Guus gave a pointer to the patch, and explained:

He added that he'd propose this for 2.5 when the time came. There was no reply to this, but Andi's reply to the original post, was that equalization on the routing cache layer was too slow or not fine-grained enough, for inclusion in the main sources. Someone asked for more explanation, and Andi replied:

Alexey Kuznetsov was critical of this explanation, and said that multipath routing worked perfectly when you need to split load on servers talking to enough large number of clients. Any http server is good example. He added that Andi's suggestion of the existing eql, teql and bonding devices, would introcude even worse problem of strong tcp reordering. Actually, experiments show that load balancing works only in the situations, when congestion window is bounded by 3 packets. If it is not made artificially, it occurs automatically on each connection after some amount of excessive retransmissions. Total single TCP connection throughput is never better in this case. Actually, it hints to the thought that "true load blalancing" has to involve tracking connections and avoiding reordering TCP packets. There was no reply to this, but there was a bit of implementation discussion elsewhere, along the lines of Andi's explanations.

Dave Jones posted several patches to update AFFS, although he proclaimed loudly that this code was possibly dangerous and should not be used without extensive backups. At one point, he added, I'm coding without tools to test this, so I need help from the people who are going to be using this.. I'd also appreciate feedback from other filesys/vfs guys about anything in this patch that just 'doesn't look right' I've gone from knowing nothing about fs/VFS to this diff in four days, and now my head hurts. I wouldn't be at all surprised if I've done _something_ wrong somewhere. To Dave's discussion of ongoing work and problems, Alexander Viro replied:

Matthias Andree added his sentiments, These problems you mention have been persisting in AmigaOS for years ever since links had been introduced with AmigaOS 2, PLUS, AmigaOS shell commands have had bugs so that only the GNU ported fileutils along with the FileSystem-based (as opposed to dos.library based) ixemul.library could get you rid of directory symlinks; this is partly because links had originally not been present in AmigaOS 1.x, partly because they fucked things up really bad. He went on:

Dave also replied to Alexander's harsh critique, adding, Which is probably why someone came along and wrote PFS (Professional File System) for it, and made a whole load of money from it. He asked, Anyone know if any tech-documentation on this exists? That may be an interesting filesystem to hack on when I'm done with AFFS.. Nicholai didn't know of anything for PFS, but he added, Smart File System (SFS) on the other hand is a free (as in beer) filesystem with good technical documentation. It has gained ground in the amiga community lately. He gave a pointer to an SFS page.

But Nicholai Benalal came somewhat to AmigaOS' defense in response to Alexander's stark depiction, saying, AFFS works allright under AmigaOS. It has limitations but generally it's ok. Still, a lot of people use other filesystems for AmigaOS but there are no Linux drivers for these. So the best way to transfer files between the Amiga side and Linux is still the buggy Linux affs driver :-) A lot of people pointed out that the 'tar' command might be a decent alternative. Matthias added that lack of Linux drivers for the other filesystems might have something to do with the lack of available sources for those primarily commercial filesystems. He also disagreed with Nicholai's assertion that AFFS worked passably under AmigaOS. He expressed, It blows itself off its very feet when crashing at the wrong time and leaving a system behind that's corrupted beyond repair. This is happening all over the place every now and then.

Rask Ingemann Lambertsen replied, AFFS is as good (or bad) as ext2 in this regard. But Matthias and Alexander both objected to this. Alexander said, It is not. You need much more atomic operations to get from one valid state of filesystem to another. And I mean _much_ more - as minimum twice. Data structure is designed by complete loonie - just look at it and write down the worst-case set of modifications to be done upon rename(). Pay attention to the size of critical part - _some_ steps can be performed without corrupting the structure if you fail after them, but there is a nice lump that should be taken together or not at all. Now, do the same for FFS (_real_ one, designed by sane people). Or its descendants - ext2, ufs... Compare the results. And Matthias also said, AFFS is much worse. It needs reordering hash chains, touching several and so on even on a single rename. If your machine crashes before all blocks have been written, you're in trouble, since tools that handle this do not come with AmigaOS. I've NEVER lost so much data with ext2 because of corruption as I recently lost with affs (on AmigaOS). AFFS is fine only as long as you don't touch anything.

Dragan Stancevic posted a patch to the non-Intel eepro100 driver, to provide more detailed information about installed devices, and in the course of discussion, Alan Cox mentioned, I've had some discussion with intel about fixing the licensing for the eepro100 driver they released so that we can merge the two (they have support for more boards, ucode for interrupt mitigation, errata workarounds and portability and locking flaws. He added, I have a positive answer I dont quite understand 8) from the Intel lawyers. Dragon replied, I was not aware that intel is reconsidering their license... Did they give you any time frames to when the intel driver might be release under a more compatible license? And Alan Concluded, Basically once I finish talking to the lawyer. I've just not had time and I'll be busy next week too.

Someone purporting to be Linus Torvalds announced that he'd partnered with Microsoft and would be selling Linux from now on. Everyone rolled their eyes, but the interesting part is how quickly the identity of the poster was established. Within a day his name and various personal details were known and published. It looked as though a serious manhunt would soon be under way, until Michael Talbot-Wilson said, Hey, guys. Enough, huh? He intentionally made it clear enough that it was a joke. Fun for a couple of minutes, right?

Continuing from last week in , Bert Hubert announced: