Kernel Traffic #238 For 27�Oct�2003

There were 437 different contributors. 206 posted more than once. 171 posted last week too.

8�Oct�2003�-�20�Oct�2003 (33 posts) Subject: "Linux 2.6.0-test7 - stability freeze"

The -test7 kernel is out there now - I'm not reaching bkbits.net, but it's on the other BK sites, and the tar-ball and patches are uploading to kernel.org right now.

The biggest part of the test7 patches are:

s390 update
DVB update
NFS (v4 in particular) update
cpufreq updates
ACPI update

A lot of the rest are basically a lot of small onelines, along with fairly minor updates (networking fixes for shared skb's for remaining cases, janitorials, cleanups etc).

The more interesting thing is that I and Andrew are trying to calm down development, and I do _not_ want to see patches that don't fix a real and clear bug. In other words, the "cleanup and janitorial" stuff is on hold, and -test8 and then -test9 should be for _stability_ fixes only.

In other words, this should calm things down so that by the end of October we can look at the state of 2.6.0 without having a lot of noise from "not strictly necessary" stuff.

10�Oct�2003�-�17�Oct�2003 (14 posts) Subject: "[PATCH] Altix I/O code cleanup"

Patrick Gefre posted some Altix I/O cleanups, but David Mosberger refused to apply the patches, saying, "Unfortunately, the 2.6 tree is closed for cleanups. I would _like_ to see the patch applied, though. Perhaps you could talk to Andrew and see if you can get an exception?" Christoph Hellwig said, "Sounds strange to apply this rule for a particular architecture that just managed to compile again on 2.6 and has a huge backlog of cleanups and restructuring now..." Andrew Morton replied:

Well there are two reasons for discouraging cleanups. The first is of course that they can destabilise things. But the other is that we want as many developers as possible (Hi, Jesse) concentrating on stabilisation.

I hereby introduce the "bugzilla tax". The cost of each cleanup is two fixes for open bugzilla entries.

But if David really wants this change, and ongoing stabilisation work will be based on top of it then yes, it probably should go in after good testing.

11�Oct�2003�-�19�Oct�2003 (4 posts) Subject: "[RFC][PATCH] deb target"

I sent this to the listed contact for kbuild first, but Michael Elizabeth Chastain tells me he is no longer active in kernel development and the kbuild-devel list seems both inactive and defunct (my post never made it to any of the list archives), so I'm reposting this here.

For a while now I've been missing a deb target in kbuild, especially since there is a simple rpm target. While Debian does have a tool to create kernel packages (make-kpkg from the kernel-package package) I felt there was a need for a simpler method build into kbuild.

The patch is imperfect and could use some changes from someone who is more familiar with kbuild, but It Works For Me(tm). I would appreciate any feedback people have on it.

Sam Ravnborg said the patch could not be applied because of Linus' and Andrew's freeze, but that he (Sam) would save the patch for when it could be applied. Later, Wichert posted a new version of the patch, saying:

Here is a new versino of my make deb patch. There are a few changes since the previous version:

no longer use make install, since that will call installkernel which should not happen on package creation. Instead manually install the kernel image, config and system.map using a trick taken from scripts/mkspec to guess the filename of the kernel image.
no longer use Linus' name and email address but generate a name and email address based on the currently logged in user. This to prevent possible unwanted email to Linus.
use /etc/kernel/ for install/removal handling scripts. This will also be supported by the next version of Debian's kernel-package.
obligatory typo fixes.

A third version of this patch. A few important changes:

make boot does not exist, use make all (oops)
do not try to install modules if they are not enabled
update the comments in the scripts/builddeb script to reflect the new naming for pre- and postinstall scripts.
do not abort when running make debclean when there is nothing to clean

Christoph Pleger discovered that he was unable to use LVM with the XFS filesystem under kernel 2.4.22; in fact, ext3 and ReiserFS wouldn't work with LVM either. Only JFS filesystem snapshots could be mounted with LVM. After doing some research, he learned that an additional kernel patch was needed to get LVM working with these other filesystems; but he couldn't locate that patch. He asked if anyone had any pointers. Marc-Christian Petersen posted it to the list, but added that Marcelo Tosatti had decided not to include it in the 2.4 kernel sources. Philippe Troin searched the archives for that discussion, but with no luck, and asked why Marcelo had made that decision. Marc-Christian said it took place in private email; and posted the relevant bit. In that email, from September 2003, Marcelo had said he wanted to add some VM patches first, and that "LVM has already been updated on 2.4.23-pre. Lets do more changes later on." Philippe thanked Marc-Christian, and summarized, "Nothing technical then, Marcelo is just being slow for stability's sake and easier testing. I guess that will go in somewhere in a later 23-pre or in 24." Meanwhile, Marcelo also replied to the list, explaining that the LVM patch had not been accepted "Because the patch touches generic fs code. Dont use LVM with XFS for now." Christoph Pleger said he'd used LVM and XFS together without a problem, and asked why Marcelo had issued that caution. Marcelo replied:

Because the filesystem code lacks locking somewhere (thats what the patches adds).

It seems its not safe to create snapshots of journalled fs'es without this patch.

16�Oct�2003�-�21�Oct�2003 (17 posts) Subject: "[ANNOUNCE] udev 003 release"

I've released the 003 version of udev. It can be found at:

kernel.org/pub/linux/utils/kernel/hotplug/udev-003.tar.gz

udev is a implementation of devfs in userspace using sysfs and /sbin/hotplug. It requires a 2.6 kernel to run properly.

There have been a number of major changes since the last release:

works properly with the current 2.6 kernel (older versions of udev will not work with the current 2.6 kernel.)
persistent database support has been added, but not fully integrated (tdb is database code, very nice stuff.)
lots of documentation has been added.
spec file has been added for building rpms.
install and uninstall support added to Makefile to make it easier to install and test with.
hard coded config file paths have been fixed.
callout support has been added (allows other programs to be run to determine what to name a device.)
cross compile bugs fixed.
TODO list expanded for those who wish to help out.
lots of other stuff fixed.

The full ChangeLog is below.

The new udev FAQ is included in this release, and can also be found at:
kernel.org/pub/linux/utils/kernel/hotplug/hotplug/udev-FAQ

Development of udev is done in a BitKeeper tree available at:
bk://kernel.bkbits.net/gregkh/udev/

If anyone ever wants a snapshot of the current tree, due to not using BitKeeper, or other reasons, is always available at any time by asking.

Martin Schlemmer was happy to see this, but asked, "Is it possible to maintain naming of tarball/version ? Meaning, say we forget about the 003 version, could the next be 0.4, or even 0.3.1 or whatever ? Just changing makes trying to keep packages sane a hassle. Thanks :)" Greg replied, "The naming will be consistant from now on. Next release will be 004, followed by 005, and so on. Remember, version numbers mean nothing :). As there is no installed base before 003, I don't think this will really be a problem, do you?" Martin said, "Well, if you had an 0.2 already, 003 sorda comes and screw the pooch (if trying to work with a package manager - although it seems we are OK with ours seeing 003 as the later) :)" . And Greg replied, "Exactly, switching this early is fine by all of the package managers I've looked at."

I've released the 004 version of udev. It can be found at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-004.tar.gz

Thanks to Robert Love, there are now rpms available at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-004-1.i386.rpm
with the source rpm at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-004-1.src.rpm

udev is a implementation of devfs in userspace using sysfs and /sbin/hotplug. It requires a 2.6 kernel to run properly.

The major changes since the 003 release are:

MAJOR speedups over the previous version. No more "sleep(1)" always, we now wait for the "dev" file to show up, and not blindly guess.
partitions now work again.
removal of devices that were named differently from the kernel name work properly.
proper spec file.
a man page with real content.
sync up with current version of libsysfs.

Many thanks to Dan Stekloff, Kay Sievers, and Robert Love for their help with patches for this release. I really appreciate it.

The full ChangeLog can be found below.

The udev FAQ can be found at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ

Development of udev is done in a BitKeeper tree available at:
bk://kernel.bkbits.net/gregkh/udev/

If anyone ever wants a snapshot of the current tree, due to not using BitKeeper, or other reasons, is always available at any time by asking.

Jesse Barnes reported, "Thanks for the new release, Greg. I just tried it out on a system with some disks, but a bunch of udev processes ended up hanging." He posted a patch, which Greg accepted.

More changes than I would have liked, but most of them are fairly small. The most noticeable changes:

fix the /proc/PID/stat oops that multiple people reported
workaround for Athlon prefetch bug (occasional spurious page faults)
fix serverworks PIO autotuning
fix some cpufrequency calculations
make NFS O_DIRECT work

The rest are some architecture and driver updates, mostly stuff that people had queued up and convinced me I wanted to merge before freezing down totally.

I've flamed a number of people who flaunted the freeze (I cursed a lot more than I usually do ;), and they won't have any excuse to do so for test9. So expect the patches to shrink considerably in the coming weeks.

17�Oct�2003�-�20�Oct�2003 (18 posts) Subject: "Where's the bzip2 compressed linux-kernel patch?"

I just rewrote bunzip2 for busybox in about 500 lines of C (and a good chunk of that's comments), which comiles to a bit under 7k, and I was thinking of redoing the bunzip-the-kernel patch with my new bunzip code, but I can't find the patch. Anybody got a URL to it?

The most recent one I could find was kerneltrap's 404-error link to http://chrissicool.piranho.com/patch-2.4.x-bzip2-i386

If you're curious about the micro-bunzip code, it's in busybox CVS: http://www.busybox.net/cgi-bin/cvsweb/busybox/archival/libunarchive/decompress_bunzip2.c

Erik Andersen gave an updated link to the kerneltrap page. Elsewhere, Nick Piggin said that this topic had been discussed, and "the conclusion was that runtime memory usage and speed, and not so significant compression improvement over gzip." Daniel Egger pointed out:

A quick test with a PowerPC kernel and the normal vmlinux image reveals that this is nonsense.

-rwxr-xr-x    1 root     root      2766490 2003-09-27 22:29 vmlinux
-rwxr-xr-x    1 root     root      1149410 2003-09-27 22:29 vmlinux.gz
-rwxr-xr-x    1 root     root      1062999 2003-09-27 22:29 vmlinux.bz2

This is a 86411 bytes or 8.1% reduction, seems significant to me...

Granted, it takes 9 times as long to decompress the kernel and ca. 900kb more memory but considering an embedded DSL router I'm working with which has 16MB RAM but only 4MB Flash this is certainly worth it. At least when the target is an embedded device.

Nick said he hadn't meant that the improvement was completely unmeasurable, and agreed that there might be a use for such a feature in certain cases. Michael Buesch suggested making it a configuration option; and Rob replied, "That's what the patch against 2.4 did. I'm banging on a 2.6 version, but Manuel's continuing to optimize bunzip over in busybox cvs (I'm good at cleaning up and simplifying, but he's way better at optimizing), and I'm waiting ot see the results (and starting a micro-version of the compression side code in the meantime, which is irrelevant here...)"

Carlos Fernandez Sanz asked about the status of HPT 374 support. He knew that HP provided binaries, but he needed something that would work for other kernel builds. Mans Rullgard replied, "Works fine with 2.4.21 and 2.6.0-testX, at least. I guess 2.4.22 should work too, but I haven't tried it." Tomi Orava, however, reported, "in my experience the included kernel driver doesn't work reliable at all with my hardware either. I have tried all possible kernel versions up to and including 2.4.23-pre5 without success." He did confirm that the binary-only drivers seemed to work fine.

Elsewhere, Joel Smith confirmed that "In 2.4.21 and 2.4.22 it's working great for me. I'm using the "experimental" IDE Raid with two disks on a HPT 374 controller with the drivers that come with the kernel." Later he added that he built his kernel with all modules compiled directly into the binary. Tomi and others went back and forth trying to figure out why the feature worked fine for some folks, and not at all for others.

Ben Collins reported, "After a few people pointed out an inconsistency in the bksvn gateway, I rebuilt the 2.4 and 2.5/2.6 repo's. Anyone with those trees checked out will need to kill them and do a fresh checkout. If you have changes local in your repo, you can still do a diff to bring them over to the new checkout, since diff uses local copies, and doesn't contact the remote repo." Ramon Rey Vicente was very happy to hear of the fix, and thanked Ben.

21�Oct�2003 (8 posts) Subject: "[2.6.0-test8] Difference between Software Suspend and Suspend-to-disk?"

Jan De Luyck noticed two kernel options, "Software Suspend", and "Suspend-to-Disk". He asked what the difference was between them, and Tomas Szepe said bluntly, "They're competing implementations of the same mechanism." Mans Rullgard replied, "And neither one works reliably, I might add. They both appear to save the current state to disk, but no matter what I try, I can't make it resume properly." Felipe Alfaro Solana confirmed that he couldn't resume the system once it was suspended, and Stefan Smietanowski joked, "That's why it's called Software Suspend and Suspend-to-Disk. The matching components Software Resume and Resume-from-Disk don't work yet :)"

21�Oct�2003 (3 posts) Subject: "[patch] updated exec-shield patch, 2.4/2.6 -G4"

Here's the latest, -G4 update of the exec-shield patches, against various kernels:

redhat.com/~mingo/exec-shield/exec-shield-2.6.0-test8-G4
redhat.com/~mingo/exec-shield/exec-shield-2.6.0-test8-mm1-G4
redhat.com/~mingo/exec-shield/exec-shield-2.4.22-G4
redhat.com/~mingo/exec-shield/exec-shield-2.4.22-ac1-nptl-G4

Changes in -G4:

bugfix in the 2.6 patches, certain applications segfaulted when the stack limit was set to unlimited. (Roland McGrath)
PIE bugfix: for certain ELF layouts the kernel loader ended up overmapping ld.so resulting in broken applications. (Jakub Jelinek, me)
port to 2.6.0-test8-mm1. (Valdis Kletnieks, me)

Gianni Tedesco was very happy to see this, and Arjan van de Ven also added, "2.6 rpms for RHL with this patch are available at http://people.redhat.com/arjanv/2.5"

Someone noticed that in September, a new kernel book called "Linux Kernel Development" had come out, written by Robert Love. He or she asked if anyone on the list had read it, and what they thought of it. Michael Buesch asked Robert, "Is there some "snapshot" or preview of the content somewhere on the internet? Google didn't spit out something for my request." Robert said the thread was a little off-topic, but that "you can get a TOC and some other information from http://tech9.net/rml/kernel_book/" . And Remi Colinet gave a link to http://www.linuxshelf.com/servlet/books?category=kernel.

For those interested, I (Zack) also played a small role in the creation of Robert's book, as technical editor, and I had a great time doing it. It's a lot of fun to see the development of ideas in a work like that. I also think the final result is really useful and interesting. Robert really knows his stuff, and it shows. As a participant, I know I'm not supposed to recommend it, but I do. It's a very good book.

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

1.	8�Oct�2003�-�20�Oct�2003	(33 posts)	Linux 2.6.0-test7 Released; Stability Freeze
2.	10�Oct�2003�-�17�Oct�2003	(14 posts)	Some Altix Cleanup Code Rejected Because Of The Freeze
3.	11�Oct�2003�-�19�Oct�2003	(4 posts)	Makefile .deb Target
4.	15�Oct�2003�-�17�Oct�2003	(8 posts)	Status Of LVM With Journaled Filesystems In 2.4
5.	16�Oct�2003�-�21�Oct�2003	(17 posts)	udev 003 And 004 Released
6.	17�Oct�2003�-�18�Oct�2003	(4 posts)	Linux 2.6.0-test8 Released
7.	17�Oct�2003�-�20�Oct�2003	(18 posts)	bzip2 Compression For The Kernel Binary
8.	18�Oct�2003�-�20�Oct�2003	(23 posts)	Status Of HighPoint 374
9.	20�Oct�2003�-�21�Oct�2003	(2 posts)	Fix For The BK->SVN Gateway
10.	21�Oct�2003	(8 posts)	Status Of Software Suspend Fork
11.	21�Oct�2003	(3 posts)	exec-shield Patch Updated For 2.4 And 2.6
12.	21�Oct�2003	(4 posts)	New Kernel Book By Robert Love

Kernel Traffic #238 For 27�Oct�2003

By Zack Brown