Kernel Traffic #274 For 18 Sep 2004

I'd like to thank all the folks who sent me pointers to jobs, or who recommended me at various places. It led to a lot of interviews, a fair number of good offers, and one job that I accepted and will be starting soon.

To all the folks who helped or even sent an encouraging email, thank you! Even the interviews that didn't pan out, and the offers I had to turn down, were very good experiences, very tempting, and very much appreciated.

Some of the companies that contacted me are still in the process of looking for good technical writers, particularly in the Bay area. If there are any senior-level writers with a strong technical background out there, who want to send me their resumes, I would be happy to pass them along.

Please send them to zbrown@tumblerings.org with a subject line "KT resume submission".

I'm not getting a commission or anything like that (except possibly with the company that actually hired me), I just have an opportunity to introduce good people to good companies.

There were 762 different contributors. 397 posted more than once. 203 posted last week too.

About a year ago, I became frustrated with the process of trying to merge a bunch of cleanups that I had done to the swsusp (suspend-to-disk) code. The reasons for this were numerous, but largely irrelevant at this point. In an attempt to accelerate things, I forked the code, called it pmdisk, and merged the cleanups. I had intended to merge the two, but circumstance took another turn for the worst, and I was left with absolutely no time to tend to it, leaving the net effect a major detriment to the overall effort.

Forking the code was the wrong thing to do. I apologize to Pavel for slighting him, and the users that are still left with a suspend-to-disk implementation in limbo.

I've managed to shave off a bit of time, and have cut a set of patches that merge the two, applicable against Linus's latest BK tree. No functionality has been lost, and the cumulative benefit should be better than the previous two efforts. The short summary of the patches follow this email. The patches themselves are in seperate emails. I do not have a publically accessible BK tree, but I can work on that if anyone desires it.

In the end, these patches remove pmdisk from the kernel and clean up the swsusp code base. The result is a single code base with greatly improved code, that will hopefully help others underestand it better.

The swsusp code has also been integrated with the rest of the, albeit small, Power Managment core. This removes a bit of code duplication, and simplifies the main entry points a bit. The major benefit of this is that swsusp does not depend on /proc/acpi/sleep or a modified sys_reboot() system call to be present. It can be used by writing to /sys/power/state. The other major plus is that it can leverage the real low-power states of the platform (e.g. the ACPI S4 state), rather than always shutting the machine down.

I've done a minimal amount of testing, as I am literally on my way out the door Ottawa, but I have verified that it works on at least 1 Pentium-M based laptop (a Compaq Evo N620c). I have not had a chance to port the low-level changes to the x86-64 architecture. It's on the remaining TODO list, along with writing a more formal explanation of the technical changes for Documentation/

I'm interested to hear what people have to say about the patches and encourage everyone to give them a try. [Though, considering many people will be in Ottawa over the next week, I expect most feedback to come from there.. ]

For the acrimonious thread in which Patrick first forked the code, see Issue #231, Section #12 (3 Sep 2003: Code Fork In Software Suspend In 2.6-test) .

In response to the current post, Pavel Machek thanked Patrick, and started examining the patches. Nigel Cunningham, laden with his own patches, said he'd wait until this merge was complete before submitting his. Andrew Morton also remarked:

I'll just add Pat's BK URL to my list-of-bk-trees-to-add-to-mm-kernels. That brings it up to 25 external trees, believe it or not.

Pat, that means that anything which you commit gets autosucked into -mm, so if there is a different URL which I should be using, please let me know.

I've created a directory to store known pending v2.4 problems, at http://master.kernel.org/~marcelo/pending-2.4-issues/

INDEX says:
This is the list of pending known pending v2.4 problems, each file represents one issue. Yes, this could be improved, but its KISS right now.

And there's currently only one entry, named "loopback-highmem", which describes a (aha!) loopback highmem deadlock which is still unsolved.

Feel free to mail me detailed description of any other pending problems!

I hope this way we can map the pending and/or not-to-be-fixed issues in a central place.

Zwane Mwaikambo suggested snarfing bug reports from bugzilla.kernel.org, and Marcelo thanked him and began to do this.

James Morris said, "This patch deletes cryptoloop, which is buggy, unmaintained, and reportedly has mutliple security weaknesses. Dropping cryptoloop should also help dm-crypt receive more testing and review." Andrew Morton replied, "OK - if nobody complains convincingly we'll drop cryptoloop out of 2.6.9." Dale Fountain replied, "Cryptoloop is deprecated (since 2.6.4), but that doesn't mean it should be deleted. As is the case with many deprecated APIs, they usually hang around for a long time (until the next major rev) so that people have a chance to transition their tools. Is no one else using cryptoloop? Are 5 minor revs really enough time (so far about 5 months)?" He suggested, "Ditching cryptoloop completely in 2.7 after dm-crypt matures would be a better idea." James replied:

Part of the reason for dropping cryptoloop is to help dm-crypt mature more quickly.

I've had some off-list email on the security of dm-crypt, and it seems that it does need some work. We need to get the security right more than we need to worry about these other issues.

Let's drop the technically inferior of the two (cryptoloop) and concentrate on fixing the other (dm-crypt).

Andrew also remarked, "my most serious concern with cryptoloop is the claim that it is insufficiently secure. If this is true then we'd be better off removing the feature altogether rather than (mis)leading our users into thinking that their data is secure."

At one point, Andrew also said he'd like to hear from anyone who'd be inconvenienced by the removal of cryptoloop; and Walter Hofmann said:

I use cryptoloop and I would be really annoyed if it disappeared in the stable kernel series. Besides, I read in another mail in this thread that dm-crypt will not work with file-based storage (I'm using cryptoloop on a file), and that it is new and potentially buggy.

I'm really surprised that people here argue that dm-crypt doesn't get enough testing so cryptoloop has to go to force people to test dm-crypt with their valuable data. This is all upside-down. First dm-crypt has to be stable, safe and feature-complete, then people can convert their data to dm-crypt and only then can cryptoloop be deleted.

Some folks offered advice for the migration to dm-crypt; while some others affirmed they were in the same boat with Walter, and wouldn't like to see cryptoloop removed until there was a clear alternative.

Cryptoloop first appeared in Issue #223, Section #3 (2 Jul 2003: Encryption Over Loopback; API Changes In 2.5) . Marcelo Tosatti's attitude toward cryptoloop in the 2.4 series was covered in Issue #251, Section #29 (23 Jan 2004: Linux 2.4.25-pre7 Released; Status Of 2.4 Deep Freeze) . Andrew Morton suggested removing cryptoloop in the 2.6 tree, in Issue #255, Section #7 (17 Feb 2004: Linux 2.6.3-mm1 Released) .

This adds VLAN support to the 3c59x/90x series hardware.

Stefan de Konink ported this code from the 2.4 VLAN patches and tested it extensively. I cleaned up the ifdefs and fixed a problem with bracketing that made older cards fail.

Ben Greear was happy to see this, and asked "how large of an MTU these cards can support." Alan replied, "In VLAN mode they support just the extra VLAN bits, with the length checking turned off its either FDDI or jumbo frame size but I don't remember which. I think FDDI."

Sigh. This has been floating about for ever. My reluctance stemmed from largely-theoretical-sounding objections from Don Becker which I didn't fully understand at the time and have now forgotten.

Ben, does the patch look complete/correct to you?

Ben said the patch looked OK to him, although he didn't have the hardware to test it. But he did add, "In my opinion Becker's complaints were invalid" . The discussion moved into the technical details, where it stayed to the end.

Tons of small fixes all around the tree.

There's an optimized assembly AES implementation for x86 (from Brian Gladman), and a number of driver updates, all of which are reasonably minor.

It would be good if people only sent serious stuff for a while, and we can do a real 2.6.8, ok?

There were some scattered bug reports and other comments, and one serious licensing objection from Jari Ruusu, who claimed that his crypto contribution was licensed under the three-clause BSD license, and that no one had permission to change that. "Either use original license or drop this code," he said. Linus replied, "We'll drop it immediately. It should be easy enough to get somebody saner than you to re-convert from the original AES code which is dual-GPL'd." James Morris posted a patch to revert Jari's contribution; and promised a new version would be ready soon.

Elsewhere, Patrick McFarland asked, "will 2.6.8-rc4 be released with no optimized aes, or with a saner optimized aes?" Linus replied:

We'll see just how quickly somebody steps up to the plate. I spent some time taking the original Gladman source into gas format, and have a really ugly (untested) direct conversion if somebody wants to work on it.

Side note: Jari Ruusu has himself been distributing the code he now objects to as part of his own linux kernel loop-aes patches. From the loop-aes README:

Copyright 2001,2002,2003,2004 by Jari Ruusu.
Redistribution of this file is permitted under the GNU Public License.

But the original x86 assembler code that is part of that loop-aes patch was copyright Dr Brian Gladman, and was NOT originally under the GPL, so it was Jari Ruusu who originally did something very suspect from a copyright angle. Now he claims he never wanted to GPL it, but the fact is, he's been distributing kernel patches with the code for a long time, and claiming it is GPL'd.

So then David and James wanted to include it into the kernel as part of the standard encryption layer, and I said no, since I felt the copyright wasn't clear. So James asked Dr Gladman for permission to dual-license under the GPL, and got it. So I was happy.

Now Jari Ruusu comes along and starts complaining about things.

Jari: mitä helvetin järkeä tuossa on? Selitä.

Elsewhere it was pointed out that the BSD license allows the code it covers to be released under additional licenses as well, even proprietary licenses. This is what allowed Apple to create OS X. But in the current context, Arjan van de Ven said, "it's outright rude to take someone else's code and relicense it." H. Peter Anvin replied, "Rude, yes; that of course makes a lot of companies which have done this with BSD very rude :)"

Elsewhere, Linus and Jari had a heated argument about the nature of GPL-compatibility. Linus said at one point:

It's just _so_ much nicer to work with a code-base where none of the authors might complain about being included.

So even if the original license is GPL-compatible, just the fact that Jari doesn't want his work re-licensed means that I don't want his work in the kernel - whether it's a legal issue or not.

Now, I obviously believe that Jari has acted like an ass, since he has used the very same code under the GPL before, but hey, that's his problem.

Jari - please stop distributing your loop-aes patches. If you consider the license to be non-GPL-compatible, then you have no business distributing the thing as kernel patches. Alternatively, just say it's GPL'd. You can't have it both ways.

Jari said that his patches were GPL-compatible, adding, "Most of the files in loop-AES are licensed under GPL. Some files have less restrictive license, but are still licensed under GPL-compatible license. I am not aware of any files in loop-AES that are GPL-incompatible." Linus replied:

You're saying that you consider Gladman's original AES license to be GPL-compatible (ie a subset of it)? That's fine - apparently the FSF agrees.

However, that is incompatible with you then complaining when it gets released under the GPL. If the original license was a proper subset of the GPL, then it can _always_ be re-released under the GPL, and you don't have anything to complain about.

So which is it? Either it's GPL-compatible or it isn't. If it is GPL-compatible, why are you making noises? And if it is not, why are you claiming that you can distribute loop-AES as a GPL'd project?

You seem to be very very confused, Jari. There really _are_ only these two cases:

the AES code is GPL-compatible

This fundamentally means that it has no more restrictions than the GPL, and that in turn means that it can always be re-licensed as GPL'd code. Which James Morris did (well, it was dual-licensed, but the only license that matters for the _kernel_ is the GPL).

In this case, you can't say "you can't do that". I'm sorry, but James _can_ do that, and it is _you_ who can't do that.
the AES code is _not_ GPL compatible.

This fundamentally means that you can't relicense it under the GPL, but it _also_ means that you can't link it with GPL code, since the GPL _requires_ that the code be under the GPL. In this case, loop-AES was always wrogn and lying about beign GPL'd, and you should stop distributing it immediately.

You can't have it both ways. And there aren't any third alternatives.

Explain yourself.

Jari again affirmed the code was GPL-compatible, but he said, "you are mixing two completely different rights here; re-distribution right and re-licensing right. Original license grants you GPL-compatible re-distribution rights, which means that the code can be distributed and linked with GPL code just fine. To relicense the code under more restrictive license you need permission from all authors of the code. You clearly do not have such permission from all authors. Therefore, you can not re-license the code." Linus came back with:

Copyright law has nothing to do with "licensing". In fact, if you actually read copyright law, you will find that the _only_ thing that it's about is the right to distribute a work and the right to make derived works.

(Side note: there are also certain "right of attribution" etc, but that's still not about re-licensing and those are about the author, not the owner of the copyright).

In other words, being the "owner" of a work has nothing to do with the right to "relicence".

Being able to license somebody else to distribute the work does NOT require ownership. It only requires a _license_ to do so. You can keep owning your copyright, and let somebody else distribute the copy for you by liccensing him to do that.

And a license like the BSD license that allows very broad rights to _everybody_ means that pretty much everybody can not only distribute it, but since the BSD license doesn't even limit how they re-distribute it, you can distribute it with some additional requirements of your own.

Why do you think Microsoft etc can take BSD code and then slap their EULA on it? Right. They were given the right to distribute.

The GPL doesn't say "you can link this with a GPL-compatible license". It says:

b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

Notice? It says "this License". Not "this license or some more permissive license".

The ONLY license you can use to create a GPL derivative is the GPL itself.

And the way "GPL-compatible" licenses work is _exactly_ because these licenses are "weaker" than the GPL, and as such can always be _relicensed_ as the GPL.

THAT IS WHAT GPL-COMPATIBLE MEANS!

So when you claim that the code isn't GPL-compatible, and at the same time claim that we can't re-license it under the GPL, you are very very confused indeed. Either it is GPL-compatible, or it is not. And if it is GPL-compatible, that ABSOLUTELY means that it can be relicensed under the GPL.

Comprende?

Anyway, the point is moot. We've removed the code you touched, and I'm about to apply the new version that is based on Gladman's code (I did the conversion myself, and James Morris did the final stuff and the integration with the rest of the code).

And we did that not for legal reasons, but because quite frankly, I don't want to have _anything_ to do with somebody as confused as you are.

Jari took another look at the GPL, and admitted that he had made a mistake. He said:

I don't have any other choice here than to permit re-licencing the code. My 04-Aug-2004 18:04:46 +0300 posting where I denied re-licencing right was completely wrong. I'm sorry about that.

For loop-AES users I uploaded a patch here that updates licenses to be GPL-compatible: http://loop-aes.sourceforge.net/updates/aes-GPL.diff

Hey, Welcome back, Jari.

It's easy to be wrong. It's much harder to come out and say so.

Let's leave this spat behind us. Friends?

Pat Gefre announced that he and the other Altix developers had reorganized the Altix code. He said:

The general changes are:

added new hardware support
code cleanup (typedefs, include files, etc.)
simplified the directory structure (all files were arch/ia64/sn/io/ are now under arch/ia64/sn/ioif/)
code size reduced by >50%
major reorg of the code itself
copyright updates

Christoph Hellwig examined the patches, and had some severe criticisms. He said:

Yikes, this is truely horrible. First your patch ordering doesn't make any sense, with just the first patch applied the system won't work at all. Please submit a series of _small_ patches going from A to B keeping the code working everywhere inbetween.

Your new directory structure is very bad. Just stick all files into arch/ia64/sn/io/ instead of adding subdirectories for often just a single file.

He objected to some of the PCI work, saying, "you're adding tons of non-standard SAL calls for who knows what. In fact this pretty much looks like you're just moving the existing crappy code into the prom so the bad Linux guys can't complain about it anymore. Please switch to the standard ACPI PCI probing mechanism all other IA64 machines support and you can get rid of all that." He also pointed out that the kernel debugger (KDB) support functions didn't belong in the mainline kernel, because KDB wasn't in mainline. He said the proper place for those functions was in the KDB patch itself. Keith Owens replied, "kdb is an extensible debugger. Subsystems can add their own kdb commands to decode their own data. Those extensions to kdb belong in the subsystem code, not in the main kdb patch." But Christoph replied, "They do not belong into mainline. kdb isn't in mainline and we shouldn't carry code for it around. I don't care whether you want it in the kdb patch or whatether it's in a separate one."

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.8-rc3/2.6.8-rc3-mm1/

Added David Woodhouse's MTD tree to the "external trees" list
Dropped the staircase scheduler, mainly because the schedstats patch broke it.

We learned quite a lot from having staircase in there. Now it's time for a new scheduler anyway.

Thomas Richter said, "here's a tiny patch against parport/parport_pc.c for kernel 2.4.26. It adds support for the NetMOS 9805 chip, used in several popular parallel port extension cards available here in germany. The patch below has been found working in a beige G3 Mac and a Canon BJC just fine." He added, "The same patch should also apply to more modern kernels since it just adds some PCI ids. Similar patches for other NetMOS products might be easy since they're all documented; I could add a couple of PCI Ids to the parport_pc - I just don't have the hardware for testing." Marcelo Tosatti said the patch looked good and would be going into 2.4.28, and asked Thomas to write a 2.6 version as well. Thomas said he'd give it a shot.

The patch below implements RSS ulimit enforcement for 2.6.8-rc3-mm1. It works in a very simple way: if a process has more resident memory than its RSS limit allows, we pretend it didn't access any of its pages, making it easy for the pageout code to evict the pages.

In addition to this, we don't allow a process that exceeds its RSS limit to have the swapout protection token.

I have tested the patch on my system here and it appears to be working fine.

Andrew Morton replied, "I'd kinda expected that the patch would try to limit a process to its RLIMIT_RSS all the time. So if a process is set to 16MB and tries to use 32MB it gets to do a lot of swapping. But you're not doing that. Instead, the patch is preferentially penalising processes which are over their limit when we enter page reclaim. What are the pros and cons, and what is the thinking behind this?" Rik replied:

Hard limiting a process when there is memory available means that it's trying to saturate the IO subsystem, slowing down other tasks in the system.

Basically when memory isn't the bottleneck, I think you shouldn't try to create an IO bottleneck for the other tasks in the system, just because an RLIMIT_RSS got set.

The downside is that the pages of the process need to be swapped out when something else needs the memory, but if the alternative is constant swapping, we'd have the IO overhead regardless...

Elsewhere, Andrew asked for a clear explanation of what the patch was really trying to do. He said once they knew what the patch was supposed to do, "we can then go off and see if the patch actually does it." Rik clarified:

What I want the feature to do is allow users to set an RSS rlimit to prevent a process from hogging up all the machine's memory.

I am not looking for a hard memory limit, since that would just cause extra IO, which has bad consequences for the rest of the system.

In addition, I would like the patch to be relatively low impact, not giving us much maintenance overhead or much runtime overhead.

If anybody has good reasons for needing hard per-process RSS limits, let us know. So far I haven't seen anybody with a workload that somehow requires a hard limit.

Here goes the last -rc, fixing a couple of typos to the big file offset patch from -rc5.

-final will be out in a couple of hours, now for real.

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.8-rc3/2.6.8-rc3-mm2/

Added a little patch to the CPU scheduler which disables its array switching.

This is purely experimental and will cause high-priority tasks to starve lower-priority tasks indefinitely. It is here to determine whether it is this aspect of the scheduler which caused the staircase scheduler to exhibit improved throughput in some tests on NUMAq.
If some devices mysteriously stop working, try booting with pci=routeirq. If that fixes it, please send a report, Cc'ing bjorn.helgaas@hp.com. See remove-unconditional-pci-acpi-irq-routing.patch

Espen Fjellvær Olsen asked if there were any plans to incorporate Reiser4 into the -mm tree, since it seemed stable enough for inclusion. Vladimir V. Saveliev said, "We sent it to Andrew Morton at the end of last week and he made few warnings we are currently trying to address." Hans Reiser said more confidently, "Yup, it is going in, we are finessing details right now."

Hmm.. Not a huge amount of changes, but enough that I wouldn't have felt comfortable releasing it as 2.6.8. I've been hoping to resolve the dcache reports, and we found _one_ bug, but that one would likely not affect a whole lot of people, so..

Some ARM updates, the i586 AES code rewrite, some ppc updates.. A large portion of the patch actually ends up being cleaning up some /proc files (thanks to Al for doing seq-file conversions) and me fixing some broken calling conventions in sysctl and sound /proc handling.

The shortlog gives a reasonable picture of the changes.

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.8-rc4/2.6.8-rc4-mm1/

Mainly little fixes. Some recovery from damage due to the recent large influx of patches.
I am offline for the rest of the week.

The Minneapolis Cluster Summit came and went 10 days ago, with excellent attendance and high-quality interaction all round. Over the last few days I've been collecting slide presentations and related material onto this page:

http://sources.redhat.com/cluster/events/summit2004/presentations.html

Unfortunately, due to manpower limitations and short lead time, we weren't able to arrange for audio recordings, which would have been great since both presentations and discussion were packed full of useful material. I guess this means we have to do it again next year, this time with a tape recorder! As for the results... discussion continues on linux-cluster and other mailing lists, please judge for yourself.

https://www.redhat.com/mailman/listinfo/linux-cluster
http://lists.osdl.org/mailman/listinfo/cgl_discussion
http://lists.osdl.org/mailman/listinfo/dcl_discussion

Deepak Saxena said, "Following this email will be a set of patches that provide a first pass at exporting information currently in /proc/cpuinfo to sysfs for i386 and ARM. There are applications that are dependent on /proc/cpuinfo atm, so we can't just kill it, but we should agree on a kill date and require all arches & apps to transition by that point. I've added code to proc_misc.c to remind the user that the cpuinfo interface is going away (currently using arbitrary date ~1 year from now)." [...] "I'll try to do MIPS, SH, and PPC when I get a chance (all I have access to), but have other things to do for a while" . Dave Jones made some technical remarks, and said, "The only other concern I have is the further expansion of sysfs with no particular gain over what we currently have. The sysfs variant *will* use more unreclaimable RAM than the proc version. /proc/cpuinfo has done well enough for us for quite a number of years now, what makes it so urgent to kill it now that sysfs is the virtual-fs-de-jour ?" Deepak replied that the reason to migrate cpuinfo out of /proc was "Consitency in userspace interface. My understanding is that goal is to make /proc slowly return to it's original purpose (process-information) and move other data out into sysfs." He added that the costs of migration "hasn't kept other data such as PCI and partition information from moving into sysfs." Dave said that just because some subsystems had gone that route didn't make it the right thing to do. As far as maintaining a consistent interface, Dave said, "sorry, but I think that argument is total crap. Any userspace tool needing this info will still need to support the /dev/cpu/ interfaces if they want to also run on 2.2 / 2.4 kernels." And regarding the goal of making /proc a process-only creature, Dave felt this wasn't realistic at all. He said, "It'll take years just to migrate the in-kernel stuff, and there's god alone knows how much out-of-tree code doing the same, plus the add-ons from various vendor kernels etc so I doubt it'll ever be the process-only utopia you envision." Deepak replied that of course, none of this could be accomplished over night, which was why he'd suggested a longer transition period. Dave wasn't convinced, and remained skeptical that the old interfaces should be removed at all.

Close by, Andrew Morton came in and stood between the two developers, saying that Deepak's goals "may be realistic if we try hard enough, but I don't think it's a desirable one at this time. I'd prefer that I, Deepak and everyone else be spending cycles on higher-priority things than these patches. Sorry." Greg KH replied that there was nothing wrong with Deepak having fun with the code even if it wasn't part of the general improvement of Linux. He added, "I'm going to keep Deepak's patches around in my personal trees and see how well they work out as they are something that I've personally been interested in doing for quite some time. If, after a while, things look better, I'll ask for a trial time in the -mm tree for them."

Jeff Dike posted some UML patches, and folks discussed some of their ins and outs. At one point Andrew Morton voiced his opinion on the situation, saying, "Frankly, when a subsystem gets this far out of date I don't think it matters a lot - nobody has much hope of following all the changes anyway. We'll just merge the megapatch on the assumption that Jeff knows what he's doing, and that it's better than what we had before. You should have seen the size of some of those MIPS patches ;)"

This is much different from Linus Torvalds' approach, which tends to take a much harder line on merging large patches.

As author of the current Linux SATA driver, I get the brunt of the questions and "bug reports" about "Linux doesn't support my hardware SATA RAID". Sigh. Silly marketing departments.

Thus, I have created a FAQ. You might sense a theme...

http://linux.yyz.us/sata/

Willy Tarreau replied, "I like it. It's fairly simple. I'm always amazed how many people do really believe that these cards provide hardware RAID !!! The problem is when you ask a reseller to add a real hardware RAID card in a system you purchase and you end up with a cheap silicon image... It happened to us once and it's not funny at all." Bernd Eckenfels segued, "Speaking of that, does that mean that other OSes (i.e. Windows) are using BIOS provided code to do raid, or do they also have raid software drivers and the bios is only used on bootup for signature detection and formatting?" Alan Cox replied, "Normally BIOS and windows drivers doing their raid. It isn't entirely that simple. The 3ware is hardware raid as are some of the other high end devices (eg aacraid sata boards). There are also some low end devices with part of the raid logic in hardware (some promise) although I don't believe we use that to the full yet. I'm currently trying to fix up the IT8212 which is an older PATA board which does have real h/w raid 0/1." Andrew Morton replied:

I'm sitting on the vendor's driver for these cards. How does your work differ from this?

hch questioned why we need the driver at all: just put the card in JBOD mode and use s/w raid drivers. But the thing does have an on-board CPU and the idea is that by offloading to that, the data transits the bus just a single time. The developers are off doing some comparative benchmarking at present.

Alan replied that his work differed from the vendor driver because his version "uses the IDE layer instead of badly duplicating it in essence." He added, "On my set up raid1 is materially faster using their processor and raid0 is materially faster not. There are also co-existance issues with Windows dual boot setups. The PCI single copy makes a big difference on a 32bit/33Mhz plug in card."

18. Linux 2.6.8 Released; 2.6.8.1 Paper-Bag Fix Introduces New Versioning Policy

Linus Torvalds announced Linux 2.6.8, saying, "The major patches since -rc4 were some sparc64 and parsic updates, but there's some network driver and SATA updates and a few ARM patches too. And a use-after-free fix in MTD." Willy Tarreau reported, "I've just compiled and booted 2.6.8 on my dual athlon. Everything went OK before I logged in as a non-root user whose home is mounted from another linux box over NFSv3/UDP," at which point he got an oops. Linus replied with a one-line patch, saying:

Damn. I think the stupid typo in fs/nfs/file.c from the fcntl f_op removal patch is the problem.

Andrew, since I'm gone in another hour, how about you try to make a 2.6.8.1 with this, since this is clearly a good reason for one?

Andrew said he would; but the deviation of version numbering raised some hackles among developers. Christoph Hellwig said, "Cane we make this 2.6.9 to avoid breaking all kinds of scripts expecting three-digit kernel versions?" Linus replied, "Well, we've been discussing the 2.6.x.y format for a while, so I see this as an opportunity to actually do it... Will it break automated scripts? Maybe. But on the other hand, we'll never even find out unless we try it some time." Nur Hussein remarked, "I hear the first victim of the breakage may be the kernel.org front page. 2.6.8.1 is not showing up as "latest"." Greg Norris pointed out that the patch-kernel script was also breaking on the new release (and Randy Dunlap posted a quick fix for this). Daniel Jacobowitz also pointed out, "This will break glibc's OS version checks. It won't show up as a problem now, since it's mostly used to ignore versions of libraries which are too new for the running kernel, and 2.6.8.1 is as new as it gets. But that code is going to think the version is humongously greater than 2.6.8 and 2.6.9."

Close by, Matt Mackall remarked, "We might avoid some of this" [general breakage] "(and communicate more to end users) by using the 2.4 -pre and -rc nomenclature, where a release is made by renaming an -rc kernel. As it stands, the current 2.6 "release candidate" naming is a lie - there's no intent to make it a final release." Marcelo Tosatti replied, "I agree. The renaming is done by hpa's "bless-as-final" script on master.kernel.org."

Somewhere along the 2.6 series, there was a change made that causes distclean to automatically delete the debian/ subdirectory from the top of the kernel tree. This causes grief for the official debian kernel packages; the debian directory shouldn't be deleted in the packages. Please apply the attached patch; it causes the debian/ subdirectory to only be deleted if there's no debian/official.

An even better solution would be to mark the debian directory as being created by the kernel (touch debian/linus), and only delete it if the kernel created it.

Such special cases are not acceptable.

If this causes a problem then there are the following options:

1) Rename directory in debian or the kernel
2) Debian apply a patch to the kernel

Preference to 1).

Andres replied, "This isn't a special case; this is debian using a directory for years, and the kernel suddenly deciding to not only use the same directory, but assume ownership of it and delete it when distcleaning. By providing a rule that creates a debian package, you've managed to inconvenience the people who actually create and maintain the main system your debian package would run on. Please take this into consideration." He suggested a third item to Sam's list of alternatives, saying:

How about not deleting the directory if you haven't created it? Debian already applies patches to the kernel, but we feed changes/fixes back to linus and co; this is one of those fixes that should be in the main kernel. If you're going to provide a make rule for *Debian*, then make it consistent with Debian packaging standards. Otherwise, why even bother? Debian has its own supported methods for creating kernel packages (named, oddly enough, kernel-package).

Honestly, I'd rather see the deb rule removed completely; Debian and Debian-derived distributions provide their own kernel packages. Users who compile their own kernel have the option of using a Debian supported method for building kernel packages (they can also simply copy images around, without bothering w/ packages). Generating a package without kernel-package is not supported; does it even handle grub and lilo updates in postinst?

Sam said, "Let the kernel use a directory named 'deb' to match the deb-pkg target." And Andres replied, "That works for me. I assume the idea is to use $(SRCDIR)/deb/debian instead of $(SRCDIR)/debian." End of problem and End Of Thread.

Here goes the first 2.4.28 -pre release.

It contains a big SATA update with long list of fixes, a networking update (mainly SCTP fixes), lib crypto fixes and the addition of the Khazad algorithm, add prism54 wireless driver, SPARC64 update, cciss SCSI driver fixes, couple of storage devices added to SCSI device list, agpgart support for i915 chipset, OOM killer rare-case bugfixes, a VM bugfix which could cause deadlocks under OOM conditions, a bunch of warnings fixes, and initial support for gcc 3.4.

I still have a few bugfixes pending on my inbox, which should be merged next week.

Just released a small update to ethtool, version 2, posted at

http://sourceforge.net/projects/gkernel/

Like its cousin "blktool", ethtool now has a simplified version scheme, an ascending number.

For those unfamiliar with ethtool, it is a utility designed to configure specific features founds on most ethernet cards.

Summary of changes (mainly the new version scheme):

Feature: ethtool register dump raw mode
Feature: return results of self-test back to OS via exit(2)
Feature: add verbose register dump for pcnet32, fec_8xx
Maintenance: update to more recent autoconf
Maintenance: minor updates to e1000-specific module
Bug fix: Remove silly restriction on ethernet interface naming


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	17 Jul 2004 - 6 Aug 2004	(13 posts)	pmdisk And swsusp Reunification In Progress
2.	20 Jul 2004 - 9 Aug 2004	(11 posts)	List Of Pending 2.4 Bugs
3.	21 Jul 2004 - 7 Aug 2004	(68 posts)	Removing cryptoloop From 2.6 (or 2.7)
4.	28 Jul 2004 - 6 Aug 2004	(31 posts)	VLAN Support For 3c59x/90x Networking Cards
5.	3 Aug 2004 - 7 Aug 2004	(39 posts)	Linux 2.6.8-rc3 Released; AES Licensing Dispute And Resolution
6.	4 Aug 2004 - 12 Aug 2004	(17 posts)	Altix Code Reorganization
7.	5 Aug 2004 - 9 Aug 2004	(35 posts)	Linux 2.6.8-rc3.mm1 Released
8.	5 Aug 2004 - 6 Aug 2004	(3 posts)	NetMOS 9805 Chip Support In 2.4; 2.6 Support Planned
9.	5 Aug 2004 - 9 Aug 2004	(13 posts)	RSS ulimit Enforcement For 2.6
10.	7 Aug 2004	(2 posts)	Linux 2.4.27 Released
11.	8 Aug 2004 - 10 Aug 2004	(52 posts)	Linux 2.6.8-rc3.mm2; Reiser4 Going Into 2.6
12.	9 Aug 2004 - 16 Aug 2004	(11 posts)	Linux 2.6.8-rc4 Released
13.	9 Aug 2004 - 17 Aug 2004	(50 posts)	Linux 2.6.8-rc4-mm1 Released
14.	11 Aug 2004	(1 post)	Minneapolis Cluster Summit Summary
15.	11 Aug 2004 - 14 Aug 2004	(14 posts)	Status Of Migration From Other Interfaces To SysFS
16.	11 Aug 2004 - 18 Aug 2004	(14 posts)	Status Of 2.6 Policy Regarding Really Large Patches
17.	11 Aug 2004 - 16 Aug 2004	(26 posts)	SATA RAID FAQ
18.	13 Aug 2004 - 18 Aug 2004	(29 posts)	Linux 2.6.8 Released; 2.6.8.1 Paper-Bag Fix Introduces New Versioning Policy
19.	14 Aug 2004 - 15 Aug 2004	(5 posts)	Kernel Deleting Debian Build Directory
20.	15 Aug 2004 - 17 Aug 2004	(3 posts)	Linux 2.4.28-pre1 Released
21.	17 Aug 2004	(1 post)	ethtool Version 2 Released

Kernel Traffic #274 For 18 Sep 2004

By Zack Brown