Kernel Traffic #302 by Zack Brown
[email protected] Sat, 02 Apr 2005 22:17:09 -0800
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <[email protected]> |
Kernel Traffic #302 For 2 Apr
By Zack Brown
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Mailing List Stats For This Week
* Threads Covered
1. 23 Feb - 3 Mar (81 Linux 2.6.11-rc4-mm1 Released
posts)
2. 27 Feb - 3 Mar (4 Support For GEODE CPUs in 2.6
posts)
3. 27 Feb - 4 Mar (7 New Digi Neo Serial Port Adapter Driver
posts)
4. 28 Feb - 5 Mar (18 Status Of Modular Framebuffers
posts)
5. 1 Mar - 4 Mar (32 Linux 2.6.11-rc5-mm1 Released
posts)
6. 1 Mar - 4 Mar (4 Improving The BitKeeper->CVS Gateway
posts)
7. 2 Mar - 5 Mar (12 FUSE Going Into 2.6
posts)
8. 3 Mar - 7 Mar (37 New w.x.y.z Kernel Numbering Scheme Lumbering
posts) Forward
9. 4 Mar (1 post) Kernel Crypto API Maintainership
10. 4 Mar - 8 Mar (54 Linux 2.6.11.1 Released; Some Discussion Of
posts) Protocol
11. 4 Mar - 7 Mar (23 Guidelines For Accepting Patches Into The
posts) w.x.y.z Tree
12. 8 Mar (3 Video4Linux Maintainership
posts)
13. 9 Mar (3 Linux 2.4.30-pre3 Released
posts)
Mailing List Stats For This Week
We looked at 2428 posts in 15MB.
There were 720 different contributers. 285 posted more than once. The average
length of each message was 125 lines.
The top posters of the The top subjects of the week were:
week were:
149 posts in 751KB by 54 posts in 197KB for "Linux 2.6.11.1"
Andrew Morton 48 posts in 223KB for "[PATCH/RFC] I/O-check interface
136 posts in 763KB by for driver's error handling"
Greg KH 48 posts in 217KB for "[ACPI] Call for help: list of
87 posts in 554KB by machines with working S3"
Adrian Bunk 33 posts in 223KB for "Page fault scalability patch V18:
74 posts in 392KB by Drop first acquisition of ptl"
Domen Puncer 28 posts in 112KB for "[Alsa-devel] Re: intel 8x0 went
61 posts in 455KB by silent in 2.6.11"
Jeff Garzik
Full Statistics generated by mboxstats version 2.2
1. Linux 2.6.11-rc4-mm1 Released
23 Feb - 3 Mar (81 posts) Archive Link: "2.6.11-rc4-mm1"
Topics: Kernel Release Announcement
People: Andrew Morton
Andrew Morton announced Linux 2.6.11-rc4-mm1, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc4/
2.6.11-rc4-mm1/
+ Various fixes and updates all over the place. Things seem to have
slowed down a bit.
+ Last, final, ultimate call: if anyone has patches in here which are
2.6.11 material, please tell me.
2. Support For GEODE CPUs in 2.6
27 Feb - 3 Mar (4 posts) Archive Link: "Support for GEODE CPU's in Kernel
2.6.10."
Topics: Small Systems
People: Kianusch Sayah Karadji
Kianusch Sayah Karadji said:
This is a small patch for GEODE CPU support in Kernel 2.6.10.
Those CPU's are found mostly in embedded systems ... one of the most
prominent Hardware using GEODE CPU is probably soekris net4801 (http://
www.soekris.com).
This patch has been on my homepage (http://www.sk-tech.net/support/
soekris.html) for quite a time - but I've been asked several time to have
it included in the main kernel.
3. New Digi Neo Serial Port Adapter Driver
27 Feb - 4 Mar (7 posts) Archive Link: "[ patch 1/7] drivers/serial/jsm: new
serial device driver"
Topics: PCI
People: Wen Xiong, Christoph Hellwig, Jeff Garzik, Greg KH
Wen Xiong said:
We are submitting a new serial driver for the 2.6 kernel. This device
driver is for the Digi Neo serial port adapter.
We made some changes based on great comments from linux community. We used
the Russell's serial_core interface on 2.6 kernel, handled all
initialization of module correctly and used fs/seq_file.c interface for /
proc entry. And we made some changes based on Greg KH's comments also
including removing whitespace, changing some function comments, removing
msleep() etc.
Per requests, I split it up in smaller chunks and sent them in several
emails for you. You are able to read the code and comment the code easily.
I added more adapter descriptions for you.
Neo adapter description:
This adapter is a 920K baud non-intelligent asynchronous serial
communications adapter for PCI bus. The adapter is based on Exar 17D152
Universal PCI Dual UART IC. The adapter is mapped into the PCI bus memory
space, and offers extened UART register mapping beyond the standard 16c554
registers. This driver used serial_core.c interface on 2.6 serials of
kernel.
Jeff Garzik felt the patch had altogether too many global variables; and other
folks had criticisms too. Wen took all this into consideration, and several
days later replied:
Based on very detail comments from Jeff, Greg, Christoph Hellwig, Rik and
Nish, I modified these codes and tested it succesfully in our lab. For
patch1, major changes included:
1. removed static board limit to use dynamic list to control board
structure.
2. leak on errors.
3. removed some global variables
4. lots of others.
Jeff was happy to see the update, and asked Wen to submit the full series of
patches for consideration.
4. Status Of Modular Framebuffers
28 Feb - 5 Mar (18 posts) Archive Link: "RFC: disallow modular framebuffers"
Topics: Framebuffer, Small Systems
People: Adrian Bunk, David Vrabel, Paul Mundt, Jeff Garzik
Adrian Bunk asked:
Do modular framebuffers really make sense?
OK, distributions like to make everything modular, but all the framebuffer
drivers I've looked at parse driver specific options in their *_setup
function only in the non-modular case.
And most framebuffer drivers contain a module_exit function. Is there
really any case where this is both reasonable and working?
Jeff Garzik said this was really a case-by-case thing, but David Vrabel said
modular framebuffers made sense on embedded systems, where "you may not use the
display hardware (and would therefore like to save a bit of memory) but it's
convenient to have only one build of the kernel/modules." He also added, "It's
useful for testing if nothing else. True, the Geode framebuffer driver won't
restore the mode on unload but since the software VGA emulation on a Geode is
less than perfect (I never did work out what happened to the cursor...) I would
expect people to not use vgacon and thus there's nothing really to restore."
Paul Mundt agreed that embedded systems made good use of modular framebuffers,
adding:
It makes little sense to keep the driver constantly loaded if the device is
not being used as a console and is only seeing occasional use.
It seems more sensible to just fix up the drivers that don't do this
right.. most of the broken drivers seem to be geared at x86 anyways where
people generally don't seem to care.
It may not make a lot of sense with distributions on x86, though it is
useful if you are doing driver development on a secondary device. This is
certainly a corner case though.
5. Linux 2.6.11-rc5-mm1 Released
1 Mar - 4 Mar (32 posts) Archive Link: "2.6.11-rc5-mm1"
Topics: Access Control Lists, FS: NFS, Hot-Plugging, Kernel Release
Announcement, SMP
People: Andrew Morton
Andrew Morton announced Linux 2.6.11-rc5-mm1, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc5/
2.6.11-rc5-mm1/
+ Lots of tuning/balancing changes in the CPU scheduler. Mainly targetted
at larger SMT/SMP/NUMA machines. It's going to be hard to work out
whether these are a net benefit.
+ A pcmcia update which obsoletes cardmgr (although cardmgr still works)
and makes pcmcia work more like regular hotpluggable devices. See the
changelong in pcmcia-dont-send-eject-request-events-to-userspace.patch
for details.
+ A new reiser4 code drop.
+ A new rev of the NFS ACL code.
+ I seem to be getting a lot of patches which don't compile if you
breathe on the .config file, let alone if you try them on another
architecture. It would be nice to receive less such patches, please.
6. Improving The BitKeeper->CVS Gateway
1 Mar - 4 Mar (4 posts) Archive Link: "[BK] cvs export"
Topics: Version Control
People: Larry McVoy, Stelian Pop, Pavel Machek
Larry McVoy said:
A while back someone complained about the CVS exporter because it sometimes
groups a pile of BK changesets into one commit. That's true, it does.
I've been running tests over the BK tree and I think we can do better.
Here's the scoop: when we do an export we are going from a very bushy graph
structure to a linear graph structure. The BK graph structure represents
what happened in all the BK repos that ever came together, the CVS graph
structure is more like what would happen if all the work had been done in
CVS. What that means in practice is that the linearization sometimes
results in a single CVS commit which has multiple changesets in it. Pavel
or someone complained that the problem with that is that if you are looking
for a bug and you are searching through commits, that works fine *unless*
your bug happens to be in one of the commits which is really a pile of
changesets. Is that accurate Pavel/Andrea/Roman/etc?
In the last flamefest about BK there was all this fuss that there wasn't
enough info in the CVS export and I think that the problem described above
is the basis for 99% (or maybe 100%) of the flameage. Is that also
accurate?
I tried to point out the following and think it was lost in the noise:
while the repository commits themselves construct a very bushy graph, the
files are not at all bushy, they are extremely linear. So what does that
actually mean? The history of the repository is very parallel, that's what
creates a bushy revision history graph, but in spite of that, there is very
little parallelism in the actual files. The result of that is that when we
do the CVS export, it is true that the number of commits is about half the
number of BK commits. But the number of file deltas is only 4% less than
the number of file deltas in BK.
Pavel/Andrea/Roman/etc still were unhappy and they are justified in being
unhappy because even though we have almost all of the file history what we
don't have is all of the patch boundaries. And when you are hunting down a
bug, if you look at Documentation/BUG-HUNTING (which I wrote back in 1996
amusingly enough) the idea is to do binary search over a range of changes
in order to narrow down the cause.
Which leads us back to the problem. If you narrow things down but where you
land is one of the clustered commits which has many changesets in it then
you are stuck with having to wade through a big pile of diffs to find the
bug, those diffs consisting of multiple patches. Sound right to you Pavel/
Andrea/Roman/etc?
If so, I have to agree with you, this is a limitation of the CVS exporter.
So I've been thinking about how to fix this and have the following idea. I
want all the CVS export users to pay close attention because this either
should make you happy or not and I want to know the answer.
When we do the export we do a couple of things to make things pleasant for
you. We make sure that the timestamps on all the files in the same commit
are the same, that makes timestamp based tools work. We also shove a
comment into each file's history that looks like so: (Logical change
1.12345) so that tools that try and group things based on comments can
work.
It's that second feature that I think we can use to solve the problem,
we're finally getting to the idea. If we have a commit that is really 200
patches which touch 400 files then we can do better. Suppose that the files
in the patches are disjoint, i.e., each patch touches a different set of
files, there is no overlap. If that's true then we could change the comment
to (Logical change 1.12345.$PATCH). It's still all one CVS commit but if
you need to go working through that commit to get at the individual patches
you could, right?
One problem is that the set of files in patches may not be disjoint, the
same file may participate in multiple patches. I think we can handle that
in the following way, we put multiple comments, one for each patch, so
you'd see
(Logical change 1.12345.5)
(Logical change 1.12345.11)
(Logical change 1.12345.79)
That's not a perfect answer because now that file participates in multiple
patches and if it's the one that has the problem you'll have to wade
through the diffs for that file for that commit. But that's an extreme
corner case as far as I can tell (I have faith I'll be "educated" if I'm
wrong about that).
So, everyone including the Pavel/Andrea/Roman/etc camp, how do you feel
about this? If we were to hack the exporter to add this info do you think
that would address the problems you have with the exporter? The reason I
ask is that while I was going to just hack this in, I went to do that and
it turned into a nasty problem, both engineering and CPU wise when
exporting. So if this isn't what you wanted then I won't bother to do it.
I'm not asking if this is the same as GPLing BK or giving people free
access to 100% of the BK internal data structures, etc. What I'm asking is
if this will make the CVS export tree something you can use to get your job
done in an efficient way.
Stelian Pop replied, "Your proposal adds more information to the CVS export
tree and this is good. But as far as I can tell it still doesn't let the user
find the original patch for a change (unless you can use the extended logical
change information to access the patch somewhere else which would be acceptable
to me)." Pavel Machek also agreed Larry's proposal was better than the current
situation; but there was no discussion.
7. FUSE Going Into 2.6
2 Mar - 5 Mar (12 posts) Archive Link: "[request for inclusion] Filesystem in
Userspace "
Topics: Device Mapper, FS: CacheFS, FS: NFS, Profiling
People: Andrew Morton, Anton Altaparmakov, Miklos Szeredi, Christoph Hellwig
Miklos Szeredi asked if FUSE could be merged into the main kernel, having spent
a significant amount of time in Andrew Morton-s -mm tree. Andrew replied:
I was planning on sending FUSE into Linus in a week or two. That and
cpusets are the notable features which are 2.6.12 candidates.
+ crashdump seems permanently not-quite-ready
+ perfctr works fine, but is rather deadlocked because it is
similar-to-but-different-from ia64's perfmon, and might not be suitable
for ppc64 (although things have gone quiet on the latter front).
+ nfsacl should be OK for 2.6.12 if Trond is OK with it.
+ cachefs is a bit stuck because it's a ton of complex code and afs is
the only user of it. Wiring it up to NFS would help.
+ dm multipath is OK for 2.6.12
+ reiser4 is less clear. Once all the review comments have been addressed
and we start seeing a bit of vendor pull for it, maybe.
Anton Altaparmakov remarked:
I would certainly vote for FUSE going in. Even if it has some bits that
could be improved the code works well. It has been in global use for quite
a while. We use it in a production environment on four servers and over 650
workstations to provide a "magic symlink filesystem" (i.e. symlink XYZ
points to different place depending on which user looks at it) and we have
not experienced any problems. I have also done other testing with a
layering fs using fuse and that was very stable (but slower than the
symlink approach which is why we went for that).
FUSE may not be perfect but lets face it - which code is? And more
importantly a lot of code in the kernel is broken (for at least some
people) yet it is in the kernel and FUSE does work well...
Christoph Hellwig wanted some additional time to go over the code; and Miklos
was fine with this. It seems that, sooner or later, FUSE will be accepted into
the 2.6 tree.
8. New w.x.y.z Kernel Numbering Scheme Lumbering Forward
3 Mar - 7 Mar (37 posts) Archive Link: "[PATCH] trivial fix for 2.6.11 raid6
compilation on ppc w/ Altivec"
Topics: Version Control
People: Greg KH, Linus Torvalds, Rene Rebe, Chris Wright, Jeff Garzik
Rene Rebe posted a one-line fix for 2.6.11, and Jeff Garzik said this would be
a good candidate for a 2.6.11.y kernel release. Greg KH replied:
Ok, I've fixed up the patch and applied it to a local tree that I've set up
to catch these things (it will live at bk://kernel.bkbits.net:gregkh/
linux-2.6.11.y until Chris Wright and I set up how we are going to handle
all of this.)
Feel free to start pointing stuff like this at me and chris (we'll also be
setting up an alias for it.)
There was some wrangling over the patch, different versions surfaced, and folks
weren't sure which one would be best to apply. Another patch also appeared, for
a different problem, and Greg and Chris Wright considered whether to include
that in a 2.6.11.y release as well. Greg decided to include the new patch, but
now Linus Torvalds objected:
I don't think your process works. You never really gave people the time to
object. So for that reason you applied the first trivial raid6 thing, and
it turned out to be wrong.
I think the patches need to have a rule like "they live outside the sucker
tree for at least two days". And during that time, anybody can vote them
down (which would move them to "unapplied" status, at which point somebody
else might decide that for _their_ tree it's still the right thing to do).
And if at the end of two days, they still haven't gotten enough "yes"
votes, they'd go into "limbo" status, with one extra grace-period (ie a
reminder on whatever list about a patch that is dying). And if it can't get
enough "yeah, sure" votes even after that, it goes into the same
"unapplied" list.
In other words, I think this really does want some automation. It shouldn't
be fully automated (at the very least, somebody needs to actually check
that things patch and fix up the changeset comments etc), but the _rules_
should be automated. Otherwise they'll always be broken because of "_this_
time it's obvious", which is against the point.
Greg agreed with this, and said, "Ok, Chris and I are going to sit down and
work this all out on Tuesday. I'll hold off on applying or releasing anything
else until we fully describe the process, and set up the infrastructure."
9. Kernel Crypto API Maintainership
4 Mar (1 post) Archive Link: "New Kernel Crypto Maintainer"
People: James Morris
James Morris said:
This is to announce that Herbert Xu is now taking over my role as
co-maintainer of the kernel crypto API.
I've not been able to devote enough time to the integration of async/
hardware support, and Herbert, who has been doing excellent work in the
networking code for some time, has now thankfully stepped up to help.
Hopefully things will now move forward more quickly in this area.
10. Linux 2.6.11.1 Released; Some Discussion Of Protocol
4 Mar - 8 Mar (54 posts) Archive Link: "Linux 2.6.11.1"
Topics: Version Control
People: Greg KH, Ian Pilcher, Linus Torvalds, Andrew Morton, Russell King,
Chris Wright, Jeff Garzik
Greg KH said:
For those of you who haven't waded through the huge "RFD: Kernel release
numbering" thread on lkml to realize that we are now going to start putting
out 2.6.x.y releases, here's the summary:
A few of us $suckers will be trying to maintain a 2.6.x.y set of
releases that happen after 2.6.x is released. It will contain only a
set of bugfixes and security fixes that meet a strict set of
guidelines, as defined by Linus at:
http://article.gmane.org/gmane.linux.kernel/283396
Chris Wright and I are going to start working on doing this work, we will
have a <SOME_ALIAS>@kernel.org to post these types of bug fixes to, and a
set of people we bounce the patches off of to test for "smells good"
validation. We will also have a bk-commits type mailing list for those who
want to watch the patches flow in, and a bk tree from which changsets can
be pulled from.
Chris and I will be hashing all of the details out next Tuesday, and
hopefully all the infrastructure will be in place soon. When that happens,
we will post the full details on how all of this is going to work. In the
meantime, feel free to CC: me and Chris on patches that everyone thinks
should go into the 2.6.11.y releases.
But right now, Chris is on a plane, and we don't have the email alias set
up, or the proper permissions set up on kernel.org to push changes into the
v2.6 directory, but we have a few bugs that are needing to be fixed in the
2.6.11 release. And since our mantra is, "release early and often", here's
the first release.
---------------
I've released the 2.6.11.1 patch:
kernel.org/pub/linux/kernel/people/gregkh/v2.6.11/patch-2.6.11.1.gz (http:/
/www.kernel.org/pub/linux/kernel/people/gregkh/v2.6.11/patch-2.6.11.1.gz)
With a detailed changelog at:
kernel.org/pub/linux/kernel/people/gregkh/v2.6.11/ChangeLog-2.6.11.1 (http:
//www.kernel.org/pub/linux/kernel/people/gregkh/v2.6.11/ChangeLog-2.6.11.1)
A bitkeeper tree for the 2.6.11.y releases can be found at:
bk://linux-release.bkbits.net/linux-2.6.11
The diffstat and short summary of the fixes are below.
I'll also be replying to this message with a copy of the patch itself, as
it is small enough to do so.
A number of kernel folks burst into tears of joy to see this work. Others had
more sober comments. Ian Pilcher replied, "From a purely process point of view,
my concern would be making sure that everything that goes into 2.6.X.Y (e.g.
2.6.11.1) makes it into 2.6.X+1 (e.g. 2.6.12)." And Greg replied, "It will be
so." And somewhere else in the thread, Linus Torvalds said, "I'll just pull
from the sucker-tree."
However, this merge question turned out to be a little more complicated than
folks might have hoped. Some patches, it was revealed, would be in the w.x.y.z
tree, that were not intended for the w.x.y tree at all. Of course it would be
possible to revert the unwanted patches during the merge, which would be fine
for small stuff; but as Andrew put it, "we end up with a cset in the permanent
kernel history which simply should not have been there." Greg was surprised
that Linus and Andrew would consider this such a big deal, but Linus confirmed
that "Once? No. If it ends up being "par for the course", it's bad."
At one point, Russell King suggested bypassing this problem by having two
'sucker' trees, one with fixes intended for Linus, and another with fixes to
keep out of the main tree. Jeff Garzik thought this was a good idea, but Linus
said:
However, it's also true that the thing BK is _worst_ at is cherry-picking
things, and having a collection of stuff where somebody may end up vetoing
one patch and saying "remove that one".
So it's entirely possible that the proper tool to use for the first level
is not BK at all, but the evolved patch-scripts that Andrew uses, in other
words:
http://savannah.nongnu.org/projects/quilt
may well be a much better thing to use.
I love BK, but what BK does well is merging and maintaining trees full of
good stuff. What BK sucks at is experimental stuff where you don't know
whether something should be eventually used or not.
11. Guidelines For Accepting Patches Into The w.x.y.z Tree
4 Mar - 7 Mar (23 posts) Archive Link: "[RFQ] Rules for accepting patches
into the linux-releases tree"
Topics: Version Control
People: Greg KH, Dave Kleikamp, Valdis Kletnieks, Adam Sampson, Andries Brouwer
, Marcelo Tosatti, Ian Pilcher, Linus Torvalds
Greg KH said:
Anything else anyone can think of? Any objections to any of these? I based
them off of Linus's original list.
Rules on what kind of patches are accepted, and what ones are not, into the
"linux-release" tree.
+ It can not bigger than 100 lines, with context.
+ It must fix only one thing.
+ It must fix a real bug that bothers people (not a, "This could be a
problem..." type thing.)
+ It must fix a problem that causes a build error (but not for things
marked CONFIG_BROKEN), an oops, a hang, or a real security issue.
+ No "theoretical race condition" issues, unless an explanation of how
the race can be exploited.
+ It can not contain any "trivial" fixes in it (spelling changes,
whitespace cleanups, etc.)
Ian Pilcher suggested that one rule should be that the patch in question should
already be in Linus Torvalds's main tree. But Dave Kleikamp replied, "No, it's
cleaner in bitkeeper terms for the patches to be pulled into the linux-releases
tree first, and then Linus pulls from that. Linus has said that that is what he
intends to do." Valdis Kletnieks also said, "There's a high probability that we
hit a bug where Linus commits a more extensive "correct" solution, but 2.6.X.1
includes a much simpler band-aid that's technically bogus, but stops a
panic-on-boot bug from manifesting."
Looking at the original list, Adam Sampson asked if "a trivial patch that fixed
a data corruption issue wouldn't be accepted?" Greg agreed that this was
important, and added data corruption to the list of things that could be fixed
by one of these patches.
Elsewhere, Andries Brouwer said:
I would like the requirement: "It must be obviously correct".
In a hundred lines one can put a lot of tricky code and subtle changes. For
example, if a security problem necessitates a nontrivial change, it should
cause an earlier release of 2.6.x+1 instead of a 2.6.x.y+1.
Greg said he'd add that item to the list. Elsewhere, Marcelo Tosatti also
suggested that fixes should be acceptable if they fixed breakage of previously
working functionality.
12. Video4Linux Maintainership
8 Mar (3 posts) Archive Link: "[patch] v4l: MAINTAINERS file update."
People: Gerd Knorr, Alan Cox
Gerd Knorr said:
Goodbye, and that thanks for all the fish ;)
After several years of v4l maintainance I'm going to switch to a new work
field and will not be able to spend much time on maintaining video4linux
and the drivers, so someone else will have to step in.
I will not suddenly disappear from earth, I will be available for questions
and patch reviews for some time, but I'll stop doing active development and
most likely will not have the time to act as central patch relay for all
video4linux stuff.
Alan Cox and others thanked Gerd for all his hard work.
13. Linux 2.4.30-pre3 Released
9 Mar (3 posts) Archive Link: "Linux 2.4.30-pre3"
Topics: Serial ATA
People: Marcelo Tosatti
Marcelo Tosatti announced Linux 2.4.30-pre3, saying:
Here goes the third pre of v2.4.30.
It contains a small number of scattered fixes, most notably e1000 update, a
backport of v2.6's nForce override fix, and SATA update.
The changes which broke "tar --verify" on tapes have been reverted.
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.