Linus Torvalds announced 2.6.0-test7, saying:
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.
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.
Wichert Akkerman said:
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.
He also posted another revision:
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.
Greg KH announced:
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-FAQDevelopment 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.
Elsewhere, under the Subject: "[ANNOUNCE] udev 004 release", Greg announced:
I've released the 004 version of udev. It can be found at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-004.tar.gzThanks 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.rpmudev 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-FAQDevelopment 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.
Linus Torvalds announced 2.6.0-test8, saying:
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.
Rob Landley said:
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.bz2This 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.
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 :)
Ingo Molnar announced:
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-G4Changes 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.