Table Of Contents
|1.||29 Aug 2003 - 8 Sep 2003||(71 posts)||BitKeeper Server May Get Faster Network Connection|
|2.||30 Aug 2003 - 9 Sep 2003||(18 posts)||Power Management Work For 2.6|
|3.||2 Sep 2003 - 8 Sep 2003||(19 posts)||Separating Kernel Headers From User-Space Headers|
|4.||5 Sep 2003 - 8 Sep 2003||(6 posts)||Measuring Linux Kernel Performance|
|5.||8 Sep 2003 - 9 Sep 2003||(21 posts)||ATI Iffy On Licensing|
|6.||8 Sep 2003 - 10 Sep 2003||(14 posts)||Per-Compiler Code To Be Localized|
|7.||9 Sep 2003 - 10 Sep 2003||(10 posts)||Power Management Update|
|8.||9 Sep 2003||(3 posts)||Another Developer Migrates To BitKeeper|
|9.||9 Sep 2003 - 10 Sep 2003||(3 posts)||Removing Obsolete Documentation|
Mailing List Stats For This Week
We looked at 1569 posts in 7932K.
There were 404 different contributors. 213 posted more than once. 184 posted last week too.
The top posters of the week were:
1. BitKeeper Server May Get Faster Network Connection
29 Aug 2003 - 8 Sep 2003 (71 posts) Subject: "bandwidth for bkbits.net (good news)"
Topics: Version Control
People: Larry McVoy
Larry McVoy announced:
we're working with several vendors to try and get more bandwidth for bkbits.net. We think we have a line on a deal where we can get a full T1 just for bkbits.net for about $500/month. If we get that then we'll turn on the patch server feature so you can hit any URL and get a regular diff -Nur style patch for that changeset (or range of changesets).
We've avoiding turning on that feature in the past because we share the T1 line that bkbits.net lives on with all the rest of bitmover and we are partialy a distributed company. We do VOIP phones and when you guys clone a repo our phones don't work - that makes us look bad during a sales call. I'm not complaining, we get nice stress testing from bkbits so you should hammer on it all you want but I'd like it if we could really encourage that more. Turning on a patch server should do the trick.
ETA on this is a month.
2. Power Management Work For 2.6
30 Aug 2003 - 9 Sep 2003 (18 posts) Subject: "Power Management Update"
Topics: Power Management: ACPI, Software Suspend
People: Patrick Mochel, Pavel Machek
Patrick Mochel, who recently forked some power management / software suspend code away from Pavel Machek, announced:
I'm pleased to announce the release of the first patchset of power management changes for 2.6.0. The purpose of this release is to give people a chance to review and test the PM code before it's sent on to Linus.
These patches include a number of cleanups and fixes to the PM core code, the driver core PM code, and swsusp. I have verified that all suspend states (standby, suspend-to-ram, and suspend-to-disk) work on a number of personal systems using ACPI as the low-level power interface. However, this is with limited functionality (from a VGA console with minimal processes running).
These patches should restore suspend functionality for those that were able to successfully do it before -test3 and -test4. My apologies for the inconvenience my previous changes caused. These patches will probably not allow any more people to suspend/resume than before.
The net benefit of these, and the already committed ones, are a cleaner power management subsystem and the development of the proper framework for successfully suspending and resuming the entire system. There are still several rough edges, though we seem to be making headway on those relatively rapidly, and are my sole focus at the moment.
My main concerns right now are:
I encourage willing people to download the patch, test, and report any problems back to me and/or the list. I cannot guarantee definite or timely results for systems where PM simply doesn't work. However, the more systems we characterize, the easier this will become in the future. Please be patient.
Pavel replied with several comments, which were ignored.
3. Separating Kernel Headers From User-Space Headers
2 Sep 2003 - 8 Sep 2003 (19 posts) Subject: "kernel header separation"
People: Matthew Wilcox, Erik Andersen, David Woodhouse
Matthew Wilcox said:
In a continuing series of "Things we should have done 5 years ago, do they really need to be done before the release of 2.6.0", here's a prototype of splitting the kernel headers into stuff we want userspace to see and stuff we don't.
The basic principle is to put user headers in usr/include/linux and usr/include/asm-$(ARCH). Kernel headers may then include them as <user/foo.h> and <user-asm/foo.h>
This patch implents the 4 lines of Makefile magic necessary and converts cdrom.h to use this split. Note that we can convert headers as slowly as we care to with this scheme.
Erik Andersen was very happy to see this, and said he hoped this effort continued. He also suggested:
Header files intended for use by users should probably drop linux/types.h just include <stdint.h>,,, Then convert the types over to ISO C99 types.
David Woodhouse thought this was a good idea, adding, "In fact, we should do the rest of the kernel with as much fervour as we've been changing struct initialisers... but at least the user headers would be a good start." And Erik agreed wholeheartedly.
Matthew had other ideas for how to clean things up, but there was some thought that they might violate standards in various ways; and the conversation started to drift.
4. Measuring Linux Kernel Performance
5 Sep 2003 - 8 Sep 2003 (6 posts) Subject: "Plans for better performance metrics in upcoming kernels?"
People: Nick Piggin, Peter Chubb, Craig Thomas, Cliff White
Scott Chapman asked if there were any plans to create accurate (or at least more accurate) performance metrics in upcoming kernels. Nick Piggin replied, "Things are worked on depending on demand, and interest. I think a lot of people are put off doing good kernel metrics due to lack of good extensible userspace tools, and maybe a lack of standard ways to do the exporting." Three days after his initial post, Scott posting again, pointing out that only one person had replied, and that the issue was still very important. He hinted that he might be able to do some work on it himself, but wanted to know who to coordinate with, so he didn't end up re-doing a lot of work that had already been done. Peter Chubb replied:
I've been working on microstate acounting, and am interested in better metrics overall, for capacity planning and for accounting.
I think that SGI also have been doing some work -- see http://oss.sgi.com/projects/csa/
And Craig Thomas said, "We have a project to maintain and improve systat here at OSDL. We're looking for others to help in this area, if your're interested." Cliff White added, "OSDL can also provide you hardware resources, if you want to do a project. We may be able to help some with the coordination, if bandwidth allows. OSDL is definately interested in improving performance metrics."
5. ATI Iffy On Licensing
8 Sep 2003 - 9 Sep 2003 (21 posts) Subject: "New ATI FireGL driver supports 2.6 kernel"
Topics: Forward Port
People: Mika Liljeberg, Dave Jones, Arjan van de Ven, Dennis Freise, Alan Cox, Stian Jordet
Mika Liljeberg mentioned, "ATI has released version 3.2.5 of their FireGL driver for XFree86. The driver supports all their high end graphics cards. This is the first version that has DRM support for the 2.6 series of kernels." Stian Jordet had trouble with compilation, and Mika Liljeberg remarked, "Hmm. I did manage to build it, although I got my version from here instead of ATI's site: http://www.schneider-digital.de/html/download_ati.html."
Dave Jones found the situation laughable. He said:
So the story so far..
It shouldn't have *any* need whatsoever to touch agpgart in 2.6.
The mind truly boggles.
Arjan van de Ven asked, "isn't the 2.5 AGP GPL licensed? How can ATI then include it in a bin only module ? ...." Dave replied:
They do some pretty evil stuff like..
+#ifdef STANDALONE_MODULE MODULE_LICENSE("GPL") +#endif
Some of the folks at ATI really seem to be quite clued and 'get it' (Like those responsible for sorting out the Radeon IGP GART driver). On the other side of the coin the FireGL driver folks just get worse every time. If they actually *tried* to communicate with the community what they need from agpgart that its so obviously lacking, then there'd be no need for any of this nonsense.
Dennis Freise pointed out that technically, "The ATI drivers are NOT binary-only! agpgart (modified by ATI, I suppose) is included in form of sourcecode, being compiled on installation." And Dave replied, "Linking GPL code to binary .o files, and then disabling the MODULE_LICENSE("GPL") smells pretty fishy to me." Dennis thought about this and agreed, and Alan Cox remarked, "If all the code they include is their own then they could have dual licensed it. If not and they are modifying core kernel code to add hooks for their code they aren't likely to get past the preliminary arguments about a GPL violation and it being a derivative work."
6. Per-Compiler Code To Be Localized
8 Sep 2003 - 10 Sep 2003 (14 posts) Subject: "[Patch] asm workarounds in generic header files"
People: Suresh B Siddha, Jes Sorensen, Christoph Hellwig, David Mosberger, Linus Torvalds, Sam Ravnborg
Suresh B Siddha from Intel pointed out that, "Intel ecc compiler doesn't support inline assembly. Attached patch is required to enable linux kernel build with Intel ecc compiler." Jes Sorensen objected, "It has always been the community policy that the kernel is compiled with GCC. Therefore wouldn't it be more appropriate to ask Intel to fix it's compiler than changing the kernel like this?" Christoph Hellwig also objected to Suresh's patch, saying, "No. Currently kernel is supposed to be GNU C. Using C89/C99 constructs instead of GCCisms is fine and a good idea where it makes code more readable and doesn't degrade performace. Adding hacks for propritary compilers is a very bad idea." Suresh thanked Jes and Christoph for their criticisms, and explained, "We believe that we are trying to improve the code by localizing the compiler issues (including the ones for gcc3 and Intel complier) and by introducing use of compiler intrinsics (e.g. for barrier())." But Jes replied:
I actually think this is degrading the code rather then improving it. Right now the various macros are located in the include/asm-<foo> directory next to the items where they are used. Moving it all into one big catch-all assembly file makes it a lot harder to read things and debug the code. I already took a look at the changes that went into the ia64 part of the tree and I really think that was a step backwards.
In terms of compiling the Linux kernel, I will argue that the Intel compiler is broken if it cannot handle inline assembly. Inline assembly is just too fundamental a feature for the kernel. This is totally ignoring the question of whether one should be compiling the kernel with non-GCC in the first place.
David Mosberger countered this argument, saying, "In my opinion, moving all the asm-stuff greatly improved readability of the source code. Especially for folks who are not intimately familiar with GCC asm syntax (which is hairy _and_ platform-specific)." And as far as compiling the kernel with a non-GCC compiler, David said, "I think the jury is out on this one. Clearly it's a huge benefit if you can make do without inline asm. GCC has to make lots of worst-case assumptions whenever it encounters an asm statement and, due to macros and inlining, the asm statements are not just hidden in a few leaf routines. In my opinion, this experiment is at least worth a try. If it succeeds, great, if it fails (e.g., the Intel compiler folks fail to keep up with the kernel), all we have to do is rm intel_intrin.h."
Jes agreed that reducing the amount of inline assembly in the kernel was a good thing, although he felt it was "unrealistic to think one can try and debug things in include/asm without being able to read the assembly output in the first place." David replied, "Assembly output != GCC asm statements. There are lots of assembly-savy folks that have no clue how to read/interpret the GCC asm syntax. Those folks have the option of either generating an assembly file or disassembling the resulting object file. Both approaches would let them read the resulting code without having to know exactly how the asm statement (or intrinsic) works."
Elsewhere, Linus Torvalds responded to David's assertion that moving the assembly code improved overall readability. Linus said:
I might agree, but "compiler.h" is getting increasingly messy, and this just makes it worse (and sets the stage for making it even worse in the future).
Is somebody willing to split up compiler.h into a per-compiler file (and yes, I think "gcc-2.95" is a different compiler from "gcc-3.2" in this case, since that is what most of the compiler.h #ifdef's are all about).
Then, have a config-time "set the right symbolic link" the same way we do for "/kernel-traffic/include/asm/index.html", so that we can have a set of _clean_ compiler-dependent abstractions.
At that point, we can look at adding support for non-gcc compilers without horrible problems. At least as long as the compiler otherwise is "sufficiently good" (which clearly right now includes support for inline assembly on most architectures).
Sam Ravnborg and David immediately posted patches to give this plan a start, and Suresh posted a new patch to go along with David's restructuring. Although no code was finished during the thread, the direction seemed clear by the time the discussion ended.
7. Power Management Update
9 Sep 2003 - 10 Sep 2003 (10 posts) Subject: "Power Management Update"
Topics: FS: ReiserFS, FS: sysfs, Modems, SMP, Software Suspend, USB, Version Control
People: Patrick Mochel, Subodh Shrivastava, Greg KH, Pavel Machek
Patrick Mochel announced:
Here is the next round of power management updates. BK users can get the changesets listed below from
A patch against 2.6.0-test5 can be found at
The patches for each individual changeset can be found in that directory.
The changesets there, and listed below, are cumulative, meaning they include all of the patches I posted last week. The highlights from this release are the following:
Fixed suspend-to-disk support with preempt and SMP enabled.
Suspend-to-disk will work on a UP system with SMP enabled, though it will definitely not on an SMP system. This is on the TODO list, albeit at low priority.
The code base of swsusp itself has been reverted to its state around 2.6.0-test3. A suspend-to-disk implementation called 'pmdisk' has been created in kernel/power/pmdisk.c that offers (for now) identical functionality, and an almost identical code base. That will change in the near future, as I submit more cleanups to it.
The pmdisk implementation is accessible via the sysfs interface:
echo -n disk > /sys/power/state
While swsusp is accessible via the /proc/acpi/sleep interface. It is possible to tie swsusp into the sysfs interface, and will entertain patches to do such a thing.
Note the new config menu options for pmdisk when building the kernel.
There is still a lot to do, including fixing the random crashes that some people are experiencing. I appreciate the testing people have done, and will appreciate any feedback concerning the patches or the functionality the patches implement.
Subodh Shrivastava asked, "Any chance of this patch to be released against mm series? BTW i have tried suspend to disk (2.6.0-test4-mm6) with reiserfs filesystem it worked fine and no fs corruption." Patrick was happy to hear this, and added, "Andrew picked up the last bunch of patches for the -mm series, so most of it already resides in that tree. With some luck, he'll do the same with the remaining patches. Otherwise, I can post an incremental patch on top of the latest -mm kernel." After some more testing, Subodh reported that on his 2.6.0-test5-mm1 system, "When i tried suspend to disk with my usb modem (Alcatel Speedtouch) attached, system generated oops, couldn't get a dump on disk, will send the handwritten oops later. When i tried from X suspend to disk was successful but resume failed and system rebooted itself." Greg KH replied, "There was a patch by Pavel to fix the USB core bug. To rule this out, unload the usbcore module before suspending."
For the status of work between Patrick and Pavel Machek, see Issue #231, Section #12 (3 Sep 2003: Code Fork In Software Suspend In 2.6-test) .
8. Another Developer Migrates To BitKeeper
9 Sep 2003 (3 posts) Subject: "Do I have to buy a license to use BK for kernel development?"
Topics: Version Control
People: Nigel Cunningham, Larry McVoy
Nigel Cunningham said:
I've made one or two attempts at beginning to use BK for my kernel development work, but each time I've been stuck by the licensing code. I use it for a little while, and then get a message about not being allowed to commit because of logging (or something to that effect). Can someone give me info on how to set up BK so that you don't get these issues? (I'm assuming I don't need to buy it to use it for kernel development). I should add that I'm doing 99% of my work disconnected from the internet.
Can I also suggest that info on this be added to Documentation/BK-Usage?
Larry McVoy replied:
If you are having problems with BK you might try email@example.com or firstname.lastname@example.org.
Nigel replied, "I did read the license and am happy to comply with it. I was wondering if there's something that is failing to work properly. Are there details somewhere on how BK expects to be able to send the data, or how it can be made to try to send it?"
There was no reply on-list.
9. Removing Obsolete Documentation
9 Sep 2003 - 10 Sep 2003 (3 posts) Subject: "/kernel-traffic/[PATCH]_Remove_modules.txt"
Topics: Kernel Build System
People: Rusty Russell, Arnd Bergmann, Stephen Hemminger, Linus Torvalds
Rusty Russell said:
Thanks to Stephen Hemminger for pointing out how obsolete modules.txt is.
modules.txt contains mainly ancient information which is replicated in the kconfig help message, README, makefile.txt or the modprobe manual page. The only part which is not covered elsewhere is the "building external modules" which is still being debated (and belongs under the kbuild docs). kmod.txt reference removed from index, too.
Please sent patches to update Kconfig files which referred to modules.txt in small pieces to trivial at rustcorp.com.au. Please abbreviate wording, too, as follows:
- To compile this driver as a module ( = code which can be inserted in - and removed from the running kernel whenever you want), say M here - and read <file:Documentation/modules.txt>. The module will be called - apm. + To compile this driver as a module, say M here: the + module will be called apm.
Arnd Bergmann added:
I found another such gem in Documentation/smp.tex, which was last updated more than five years ago. Favorite quote:
"A single lock is maintained across all processors. This lock is required to access the kernel space."
The whole file has only historic value and should probably be removed or have a comment that it does not apply to the current code.
Rusty agreed, and asked Linus Torvalds to delete Documentation/smp.tex.
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at 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.