Kernel Traffic #274 by Zack Brown
[email protected] Sat, 18 Sep 2004 08:24:32 -0700
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <[email protected]> |
Kernel Traffic #274 For 18 Sep
By Zack Brown
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Introduction
* Mailing List Stats For This Week
* Threads Covered
1. 17 Jul - 6 Aug (13 pmdisk And swsusp Reunification In Progress
posts)
2. 20 Jul - 9 Aug (11 List Of Pending 2.4 Bugs
posts)
3. 21 Jul - 7 Aug (68 Removing cryptoloop From 2.6 (or 2.7)
posts)
4. 28 Jul - 6 Aug (31 VLAN Support For 3c59x/90x Networking Cards
posts)
5. 3 Aug - 7 Aug (39 Linux 2.6.8-rc3 Released; AES Licensing
posts) Dispute And Resolution
6. 4 Aug - 12 Aug (17 Altix Code Reorganization
posts)
7. 5 Aug - 9 Aug (35 Linux 2.6.8-rc3.mm1 Released
posts)
8. 5 Aug - 6 Aug (3 NetMOS 9805 Chip Support In 2.4; 2.6 Support
posts) Planned
9. 5 Aug - 9 Aug (13 RSS ulimit Enforcement For 2.6
posts)
10. 7 Aug (2 Linux 2.4.27 Released
posts)
11. 8 Aug - 10 Aug (52 Linux 2.6.8-rc3.mm2; Reiser4 Going Into 2.6
posts)
12. 9 Aug - 16 Aug (11 Linux 2.6.8-rc4 Released
posts)
13. 9 Aug - 17 Aug (50 Linux 2.6.8-rc4-mm1 Released
posts)
14. 11 Aug (1 Minneapolis Cluster Summit Summary
post)
15. 11 Aug - 14 Aug (14 Status Of Migration From Other Interfaces To
posts) SysFS
16. 11 Aug - 18 Aug (14 Status Of 2.6 Policy Regarding Really Large
posts) Patches
17. 11 Aug - 16 Aug (26 SATA RAID FAQ
posts)
18. 13 Aug - 18 Aug (29 Linux 2.6.8 Released; 2.6.8.1 Paper-Bag Fix
posts) Introduces New Versioning Policy
19. 14 Aug - 15 Aug (5 Kernel Deleting Debian Build Directory
posts)
20. 15 Aug - 17 Aug (3 Linux 2.4.28-pre1 Released
posts)
21. 17 Aug (1 ethtool Version 2 Released
post)
Introduction
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 [email protected] 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.
Be well, folks.
Mailing List Stats For This Week
We looked at 3599 posts in 20130K.
There were 762 different contributors. 397 posted more than once. 203 posted
last week too.
The top posters of the week were:
* 123 posts in 610K by William Lee Irwin III
* 116 posts in 425K by Alan Cox
* 80 posts in 391K by Sam Ravnborg
* 79 posts in 394K by Adrian Bunk
* 76 posts in 286K by Pavel Machek
* Full Stats
1. pmdisk And swsusp Reunification In Progress
17 Jul - 6 Aug (13 posts) Archive Link: "[0/25] Merge pmdisk and swsusp"
Topics: Power Management: ACPI, Software Suspend
People: Patrick Mochel, Andrew Morton, Pavel Machek, Nigel Cunningham
Patrick Mochel said:
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.
Pavel, Patrick, and others continued to work on the code in a friendly way.
2. List Of Pending 2.4 Bugs
20 Jul - 9 Aug (11 posts) Archive Link: "List of pending v2.4 kernel bugs"
Topics: Big Memory Support, Bug Tracking
People: Marcelo Tosatti, Zwane Mwaikambo
Marcelo Tosatti said:
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 (http:/
/bugzilla.kernel.org) , and Marcelo thanked him and began to do this.
3. Removing cryptoloop From 2.6 (or 2.7)
21 Jul - 7 Aug (68 posts) Archive Link: "[PATCH] Delete cryptoloop"
Topics: Device Mapper
People: James Morris, Andrew Morton, Dale Fountain, Walter Hofmann, Marcelo
Tosatti
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 :
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 : Linux 2.6.3-mm1 Released) .
4. VLAN Support For 3c59x/90x Networking Cards
28 Jul - 6 Aug (31 posts) Archive Link: "PATCH: VLAN support for 3c59x/3c90x"
People: Alan Cox, Ben Greear, Andrew Morton
Alan Cox said:
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."
Elsewhere, Andrew Morton had some frustration regarding this work. He said:
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.
5. Linux 2.6.8-rc3 Released; AES Licensing Dispute And Resolution
3 Aug - 7 Aug (39 posts) Archive Link: "Linux 2.6.8-rc3"
Topics: Advanced Encryption Standard, Assembly, BSD, Kernel Release
Announcement, Microsoft
People: Linus Torvalds, Jari Ruusu, Patrick McFarland, Arjan van de Ven, H.
Peter Anvin, James Morris
Linus Torvalds announced Linux 2.6.8-rc3, saying:
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.
He went on:
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
Linus replied:
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?
6. Altix Code Reorganization
4 Aug - 12 Aug (17 posts) Archive Link: "Altix I/O code reorganization"
Topics: Power Management: ACPI
People: Pat Gefre, Christoph Hellwig, Keith Owens
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."
7. Linux 2.6.8-rc3.mm1 Released
5 Aug - 9 Aug (35 posts) Archive Link: "2.6.8-rc3-mm1"
Topics: Kernel Release Announcement
People: Andrew Morton, David Woodhouse
Andrew Morton announced Linux 2.6.8-rc3-mm1, saying:
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.
There were some bug reports and patches, but no real discussion.
8. NetMOS 9805 Chip Support In 2.4; 2.6 Support Planned
5 Aug - 6 Aug (3 posts) Archive Link: "[PATCH] NetMOS 9805 ParPort interface"
People: Thomas Richter, Marcelo Tosatti
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.
9. RSS ulimit Enforcement For 2.6
5 Aug - 9 Aug (13 posts) Archive Link: "[PATCH] RSS ulimit enforcement for
2.6.8"
People: Rik van Riel, Andrew Morton
Rik van Riel said:
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.
10. Linux 2.4.27 Released
7 Aug (2 posts) Archive Link: "Linux 2.4.27-rc6"
People: Marcelo Tosatti
Marcelo Tosatti announced Linux 2.4.27-rc6, saying:
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.
Later he released 2.4.27 with no changes.
11. Linux 2.6.8-rc3.mm2; Reiser4 Going Into 2.6
8 Aug - 10 Aug (52 posts) Archive Link: "2.6.8-rc3-mm2"
Topics: Kernel Release Announcement
People: Andrew Morton, Vladimir V. Saveliev, Hans Reiser
Andrew Morton announced Linux 2.6.8-rc3-mm2, saying:
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
[email protected]. 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."
12. Linux 2.6.8-rc4 Released
9 Aug - 16 Aug (11 posts) Archive Link: "Linux 2.6.8-rc4"
Topics: Advanced Encryption Standard, Kernel Release Announcement
People: Linus Torvalds
Linus Torvalds announced Linux 2.6.8-rc4, saying:
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.
13. Linux 2.6.8-rc4-mm1 Released
9 Aug - 17 Aug (50 posts) Archive Link: "2.6.8-rc4-mm1"
Topics: Kernel Release Announcement
People: Andrew Morton
Andrew Morton announced Linux 2.6.8-rc4-mm1, saying:
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.
14. Minneapolis Cluster Summit Summary
11 Aug (1 post) Archive Link: "[ANNOUNCE] Minneapolis Cluster Summit Wrapup"
People: Daniel Phillips
Daniel Phillips said:
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
15. Status Of Migration From Other Interfaces To SysFS
11 Aug - 14 Aug (14 posts) Archive Link: "[PATCH 0/3] Transition /proc/
cpuinfo -> sysfs"
Topics: FS: sysfs
People: Deepak Saxena, Dave Jones, Greg KH, Andrew Morton
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."
16. Status Of 2.6 Policy Regarding Really Large Patches
11 Aug - 18 Aug (14 posts) Archive Link: "[PATCH 1/3] 2.6.8-rc4-mm1 - Fix UML
build"
Topics: User-Mode Linux
People: Andrew Morton, Linus Torvalds, Jeff Dike
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.
17. SATA RAID FAQ
11 Aug - 16 Aug (26 posts) Archive Link: "Linux SATA RAID FAQ"
Topics: Disk Arrays: RAID, Disks: IDE, Serial ATA
People: Jeff Garzik, Willy Tarreau, Bernd Eckenfels, Alan Cox, Andrew Morton
Jeff Garzik said:
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
13 Aug - 18 Aug (29 posts) Archive Link: "Linux v2.6.8"
Topics: FS: NFS, Kernel Release Announcement, Serial ATA
People: Linus Torvalds, Willy Tarreau, Christoph Hellwig, Nur Hussein, Daniel
Jacobowitz, Matt Mackall, Marcelo Tosatti, Randy Dunlap, Greg Norris
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."
19. Kernel Deleting Debian Build Directory
14 Aug - 15 Aug (5 posts) Archive Link: "[PATCH] don't delete debian
directory in official debian builds"
People: Andres Salomon, Sam Ravnborg
Andres Salomon said:
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.
Sam Ravnborg replied:
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.
20. Linux 2.4.28-pre1 Released
15 Aug - 17 Aug (3 posts) Archive Link: "Linux 2.4.28-pre1"
Topics: Disks: SCSI, OOM Killer, Serial ATA, Virtual Memory
People: Marcelo Tosatti
Marcelo Tosatti announced Linux 2.4.28-pre1, saying:
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.
21. ethtool Version 2 Released
17 Aug (1 post) Archive Link: "ethtool version 2 released"
Topics: Networking
People: Jeff Garzik
Jeff Garzik said:
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
We Hope You Enjoy Kernel Traffic
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.