Kernel Traffic #253 For 7 Mar 2004

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 2034 posts in 9669K.

There were 568 different contributors. 292 posted more than once. 141 posted last week too.

The top posters of the week were:

1. Linux 2.4.25-pre6 Released

16 Jan 2004 - 4 Feb 2004 (30 posts) Archive Link: "Linux 2.4.25-pre6"

People: Marcelo TosattiJean TourrilhesAdrian Bunk

Marcelo Tosatti announced 2.4.25-pre6, saying:

This release came out so quickly because -pre5 contains a deadly mistake in one of the fs patches.

It contains SPARC/x86-64 updates, networking and crypto updates, amongst others.

Adrian Bunk reported a linker error when trying to compile Jean Tourrilhes' VIA IrDA driver as a module under this kernel. He posted a patch to fix the problem, and Jean replied, "Thanks you Adrian. Yes, I must confess that I never test non-modular build (because it doesn't work). Marcelo, would you mind including Adrian's patch in your next kernel" [...] "I tested his patch successfully with modular and static compile." Adrian asked why the linking problem had occurred in the first place; and whether it might be better to disallow static builds of that driver altogether. Jean replied:

I never looked in details at those issues. Some people claim it works, but personally I always had touble with driver init (double initialisation). I don't want to disable it if some embedded people depend on it (stable kernel => stable feature list).

My "solution" was to totally rework the driver init (and stack init) in 2.5.X and put ample warning on my web page "use static at your own risk".

2. udev 015 Released

26 Jan 2004 - 6 Feb 2004 (50 posts) Archive Link: "[ANNOUNCE] udev 015 release"

Topics: Disks: SCSI, FS: devfs, FS: sysfs, Hot-Plugging, Microsoft, USB, Version Control

People: Greg KHMartin SchlemmerChris Friesen

Greg KH announced udev 015, saying:

It can be found at: kernel.org/pub/linux/utils/kernel/hotplug/udev-015.tar.gz

rpms built against Red Hat FC1 are available at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-015-1.i386.rpm (http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-015-1.i386.rpm)
with the source rpm at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-015-1.src.rpm (http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-015-1.src.rpm)

udev allows users to have a dynamic /dev and provides the ability to have persistent device names. It uses sysfs and /sbin/hotplug and runs entirely in userspace. It requires a 2.6 kernel with CONFIG_HOTPLUG enabled to run. Please see the udev FAQ for any questions about it:
kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ (http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ)

For any udev vs devfs questions anyone might have, please see:
kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs (http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs)

Major changes from the 014 version:

What this means to users: Consider the following sysfs device:

$ tree /sys/class/input/mouse1/
/sys/class/input/mouse1/
|-- dev
|-- device -> ../../../devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0
`-- driver -> ../../../bus/usb/drivers/hid

Now this is a USB trackball. udev will follow that "device" symlink and get to the following directory:

$ tree /sys/devices/pci0000:00/0000 :00:1d.0/usb2/2-1/2-1:1.0
/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0
|-- bAlternateSetting
|-- bInterfaceClass
|-- bInterfaceNumber
|-- bInterfaceProtocol
|-- bInterfaceSubClass
|-- bNumEndpoints
|-- detach_state
|-- iInterface
`-- power
    `-- state

This is the directory of the USB interface that is bound to a mouse driver. But in itself, that directory is pretty boring, no vendor id, no product id, no manufacturer string... What a user really wants is the directory above this:

$ tree /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1
/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1
|-- 2-1:1.0
|   |-- bAlternateSetting
|   ...
|-- bConfigurationValue
|-- bDeviceClass
|-- bDeviceProtocol
|-- bDeviceSubClass
|-- bMaxPower
|-- bNumConfigurations
|-- bNumInterfaces
|-- bcdDevice
|-- bmAttributes
|-- detach_state
|-- idProduct
|-- idVendor
|-- manufacturer
|-- power
|   `-- state
|-- product
`-- speed

Now this directory contains good stuff:

$ cat /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/product
Microsoft Trackball Optical?

So, in short, you can now write a udev rule for this device as:
SYSFS_product="Microsoft Trackball*", NAME="my_trackball", SYMLINK="input/mouse1"

and it will actually work :)

This is really helpful for all USB devices, and SCSI devices on USB or Firewire buses. If anyone has any questions about this, please let me know, or bring it up on the linux-hotplug-devel mailing list.

Another big thing in this release is 'udevinfo'. It's a way to get all information out of the udev database about what devices are present, what they are called, and other good stuff. It also will walk the sysfs chain of any device and print out all information on the device which helps out a lot in creating rules for udev.

Thanks to Kay Sievers who wrote udevinfo. Great job.

Also in this release is the start of a udev daemon. It's really in 3 pieces:

This lets us keep udevsend and udevd small, and hopefully bug free. These programs still need a lot of work and polish before we feel they are stable enough to use for everyone (they are not built right now in the .rpm). Help is appreciated here.

Thanks a lot to Kay Sievers and Xiaofeng Ling for the work on udevsend and udevd. Again, I really appreciate it.

Thanks also to everyone who has send me patches for this release, a full list of everyone, and their changes is below.

udev development is done in a BitKeeper repository located at:
bk://linuxusb.bkbits.net/udev

Daily snapshots of udev from the BitKeeper tree can be found at:
http://www.codemonkey.org.uk/projects/bitkeeper/udev/
If anyone ever wants a tarball of the current bk tree, just email me.

Chris Friesen asked about the rationale of splitting the udev daemon up into the three pieces udevsend, udevd, and udev. Greg replied, "It should be faster this way. We can send off udev to run for different devices at the same time (blocking for any pending device changes for any currently running udev instances.)"

Elsewhere, Greg added that the code was under "major flux" at the moment, and that bugs and other breakage should be expected for a time.

Elsewhere, Martin Schlemmer posted a patch to allow run-time toggling of debugging code, since the current udev tree was very "noisy", and Martin wanted to have a way of turning on and off the debugging output without having to recompile. He posted a fix to his own patch, and Greg replied:

I'm going to hold off on this patch for now for a number of reasons:

Martin said he'd try again with udev 016, and see if he couldn't answer some of Greg's objections.

3. Linux 2.6.2-rc2-mm1

27 Jan 2004 - 4 Feb 2004 (36 posts) Archive Link: "2.6.2-rc2-mm1"

Topics: FS: ReiserFS, Framebuffer, Kernel Release Announcement, Networking, Power Management: ACPI, Sound: ALSA

People: Andrew MortonChristoph HellwigAntony SuterMike FedykRandy DunlapDavid S. MillerStian JordetNikita DanilovJeff Garzik

Andrew Morton announced 2.6.2-rc2-mm1, saying:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.2-rc2/2.6.2-rc2-mm1/

Christoph Hellwig asked, regarding Jeff Garzik's netdev patches, "Any plan when we'll get the damn netdev lifetime rule fixes merged? They're real life problems and have been around for a long time.." David S. Miller asked Christoph to be mroe specific, bu there was no discussion following.

Several folks suggested also including the fbdev updates, and Nikita Danilov also suggested accepting some ReiserFS 4 (http://www.namesys.com/snapshots/LATEST/all.diff.gz) updates into Andrew's tree. Stian Jordet also suggested some ISDN updates (ftp://ftp.isdn4linux.de/pub/isdn4linux/kernel/v2.6) . Antony Suter also suggested including "The WLI patchset. It has a small number of good improvements for NUMA machines and notebooks. A couple of the patches have already made it into the kernel." But Mike Fedyk felt, "Isn't that a bit much? The wli tree makes changes across the entire tree, so it isn't very localized to any specific subsystem. Though specific cleanups would be good to merge into -mm from -wli..."

Elsewhere, Randy Dunlap asked Andrew, "About kernel-janitors patches: Do you want to continue reviewing/merging the KJ patches one by one or just grab the complete patchset?" Andrew replied, "Please just send them to me in the usual manner when you think they're ready. The reject rate has been fairly high, so we need to go through them carefully."

4. Software Suspend 2.0 Released

29 Jan 2004 - 4 Feb 2004 (46 posts) Archive Link: "Software Suspend 2.0"

Topics: Big Memory Support, Bootsplash, Compression, FS: NFS, SMP, Software Suspend, USB, Version Control

People: Nigel CunninghamSebastian KuglerMichael FrankPavel MachekMarc Lehmann

Nigel Cunningham said:

Software Suspend 2.0 for Linux 2.4 and 2.6 kernels is now available from http://swsusp.sf.net. The 2.0 release is a major advance over previous versions and includes the following features:

The Software Suspend website includes extensive documentation, including known issues (primarily DRI and USB support) and FAQS. A well-used mailing list is also available.

Known issues with Suspend 2.0 are as follows:

Some of these issues have work-arounds available: check the FAQs for details.

Note that two patches are required to use suspend: one for the particular kernel version you are using (make sure you get the most recent for your kernel version), and a second (applied afterwards) contains the core files.

Special thanks go to Gabor Kuti, Pavel Machek and Florent Chabaud for their work, which I have built on; to Michael Frank for many months of extensive testing of the code, to Marc Lehmann for supplying the LZF compressor, to Bernard Blackham for maintaining the swsusp.sf.net website and especially to LinuxFund.org for their sponsorship of the project, which has allowed me to work full-time on Software Suspend over the last four months.

Finally, heres a little ditty, to be sung to the tune of the 'The Pirates Who Don't Do Anything' (http://www.bassbios.com/bodclan/pirates.mp3)

I'm just a user who wanted to suspend, I didn't want to be a kernel hacker at all! I'm just a user who wanted to suspend, and now I'm happy because I can suspend.

Well I've never been to LinuxConf
and I've never written a device driver
And I've never talked to Linus
and I'm not an expert at BK
And I don't normally get paid to do this
and I don't own any hardware manuals
And I've never been to Boston in the fall...

Sebastian Kugler replied:

First of all, congratulations to everyone contributing to swsusp, great work! Runs fast and stable here with 2.4.24, surely something I wouldn't want to miss on my Laptop. Suspending takes about 15 sec, resuming about half a minute. No problems with drivers, no unloading of modules is necessary. Also bootsplash does look very 'sexy' with swsusp.

Secondly, and 'somewhat offtopic': How the heck do I get rid of this ditty stuck in my head? ;-)

Elsewhere, several folks attempted to port the patch up to the full bleeding edge of 2.6 development, with good success.

5. Linux 2.6.2-rc2-mm2 Released

30 Jan 2004 - 6 Feb 2004 (26 posts) Archive Link: "2.6.2-rc2-mm2"

Topics: FS: XFS, Kernel Release Announcement, USB

People: Andrew Morton

Andrew Morton announced Linux 2.6.2-rc2-mm2, saying:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.2-rc2/2.6.2-rc2-mm2/

Various folks reported problems with some of Andrew's "late-arriving" patches, and Andrew uploaded a fixed version "mm2-1".

6. CPU Hotplugging Code Update

31 Jan 2004 - 5 Feb 2004 (19 posts) Archive Link: "[PATCH 3/4] 2.6.2-rc2-mm2 CPU Hotplug: The Core"

Topics: FS: sysfs, Hot-Plugging, SMP

People: Rusty RussellIngo MolnarDipankar SarmaZwane Mwaikambo

Rusty Russell posted a large patch to update CPU hotplugging. He listed the status as still experimental, and gave this documentation:

This is the arch-indep hotplug cpu code, contributed by Matt Fleming, Zwane Mwaikambo, Dipankar Sarma, Joel Schopp, Vatsa Vaddagiri and me.

Changes are designed to be NOOPs: usually by explicit use of CONFIG_HOTPLUG_CPU

The way CPUs go down is:

  1. Userspace writes 0 to sysfs ("online" attrib).
  2. The cpucontrol mutex is grabbed.
  3. The task moves onto the cpu.
  4. cpu_online(cpu) is set to false.
  5. Tasks are migrated, cpus_allowed broken if required (not kernel threads)
  6. We move back off the cpu.
  7. CPU_OFFLINE notifier is called for the cpu (kernel threads clean up).
  8. Arch-specific __cpu_die() is called.
  9. CPU_DEAD notifier is called (caches drained, etc).
  10. hotplug script is run
  11. cpucontrol mutex released.

CPUs go up as before, except with CONFIG_HOTPLUG_CPU, they can go up after boot.

Changes are:

Some folks (mainly Ingo Molnar) went over some of the technical details, and offered some implementation criticisms. A couple days down the line, Rusty posted a new patch, saying:

This is my first cut of a patch, still has some old code in it. As an attachment since it's 70k (I'll split into multiple parts later, this is the x86 part, too).

Patch against 2.6.2-rc2-mm2. Works basically, gives "APIC error on CPU1: 08(08)" under stress. Clues welcome.

Basically consists of:

  1. New file stop_machine.[ch] which takes logic out of module.c (I haven't converted module.c code over yet though).
  2. x86: arch_cpu_down_check (called before offlining) and arch_cpu_down (called when machine stopped, moves irqs).
  3. x86: idle loop code to play dead.
  4. migrate_all_tasks() called with machine stopped, and migrates kernel threads as well.
  5. cpu.c fires off a thread to do the dirty work: it schedules with interrupts still disabled on dead cpu.
  6. Most threads are happy to run on "wrong" CPUs, but slab.c reap timer needs a little fixing, and still needs to stop when CPU goes offline. softirq threads are tied to CPU: I just hacked in a check so the do nothing if CPU is offline. Moving the migration thread is safe since it should have nothing to do.
  7. Ugly change to finish_arch_switch so it doesn't re-enable interrupts if the CPU is down (switching from take_cpu_down kthread to idle task). __migrate_task() still needs check for cpu down, AFAICT.

Given it was about a day's work, I'm happy it works at all...

There were a couple more comments, but no real discussion in reply to this.

7. Working Around Buggy BIOSes That Incorrectly Report CPU Speeds

31 Jan 2004 - 6 Feb 2004 (13 posts) Archive Link: "[PATCH] powernow-k8 max speed sanity check"

People: Tony LindgrenDave JonesPavel Machek

Tony Lindgren said:

Following is a little patch to do a sanity check on the max speed and voltage values provided by the bios.

Some buggy bioses provide bad values if the cpu changes, for example, in my case the bios claims the max cpu speed is 1600MHz, while it's running at 1800MHz. (Cheapo Emachines m6805 you know...) This could also happen on machines where the cpu is upgraded.

These checks should be safe, as they only change things if the machine is already running at a higher speed than the bios claims.

Dave Jones and Pavel Machek threw their hands in the air; Dave said, "ye gads, yet another problem with eMachines PST tables." And Pavel said, "Someone should really bug them to fix their BIOS." Pavel offered his own version of some of Tony's work, and Tony picked it over for the best bits.

8. Uptime Rollover; Status Of 2.0

1 Feb 2004 - 4 Feb 2004 (26 posts) Archive Link: "Uptime counter"

People: Matthew ReppertChristian BorntraegerDavid WeinehallMatti Aarnio

Markus Hostbacka wanted to know which kernels could record uptimes greater than 497 days. Matti Aarnio replied that no 64-bit machines suffered from that limitation. Someone else said they were surprised to hear that any kernels had that limitation, and Matthew Reppert explained:

On 32-bit architectures, the uptime counter is only 32 bits wide. Each "tick" of the counter is worth 1/HZ seconds (IIRC). So, you can get the number of seconds this will hold with simple math (2^32 * 1/HZ, HZ being 100 on i386). This is about 497.1 days.

Of course, on 64-bit architectures, the counter will hold 4 billion times that, which is about as long as the Earth has existed. Apparently 2.6 has come up with a way to deal with this on 32-bit architectures.

Christian Borntraeger pointed out that running any kernel for such a long period would probably be a bad move for security, since kernel updates often contain important security fixes.

In the course of discussion, David Weinehall got in on the act, indicating that 2.0.40 might be coming out very soon, and that there would be a 2.0.41 after that as well.

9. Linux 2.6.2-rc4-mm1 Released; Status Of Possible ReiserFS Upgrade To Version 4

2 Feb 2004 - 4 Feb 2004 (19 posts) Archive Link: "2.6.2-rc3-mm1"

Topics: FS: ReiserFS, FS: XFS, Hot-Plugging, Kernel Release Announcement

People: Andrew MortonHans ReiserTomas Szepe

Andrew Morton announced Linux 2.6.2-rc3-mm1, saying:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.2-rc3/2.6.2-rc3-mm1/

Vladimir Saveliev asked what Andrew would require, in order to get Reiser4 included in the 2.6 tree. Andrew replied:

I haven't looked at it. Please send me the two patches (core kernel diff and the fs) along with complete usage instructions so that people know where to find the userspace tools, how to run them etc. Also please ensure that all mount options are documented and that any known bugs are described.

Be aware that the barriers for a new filesystem are relatively high: each one adds a significant maintenance burden to the VFS and MM developers. It will need cautious review.

But that doesn't mean we cannot get it out there, get you some more testing and exposure.

Hans Reiser replied, "Andrew, while it is your decision to make, it would be very silly to not let us upgrade ReiserFS. V4 is 2-5x the speed of V3, has more functionality, better security, is more maintainable, etc. Once V4 is as stable and tested as V3, no one in their right mind will use V3 on a new install. While we will be happy to read improvements and critiques of our implementations from a clever coder such as yourself, we aren't exactly new to the Linux Kernel, and we are one of the very few in that community who have a real QA process that we systematically apply. That is why we did not send it in many months ago: our testing is quite extensive, and we don't think users should find bugs that we can find if we make the effort. Now we are running out of bugs that we can hit. There are distros that would like to ship using Reiser4 in April." Tomas Szepe replied that version 4 still seemed unreliable, and Hans suggested grabbing the latest code, which might fix some of the issues.

10. Linux 2.6.2 "Feisty Dunnary" Released

3 Feb 2004 - 6 Feb 2004 (14 posts) Archive Link: "Linux 2.6.2 aka "Feisty Dunnart""

Topics: Kernel Release Announcement, Version Control

People: Linus TorvaldsIan SoboroffJohn BradfordAlastair Stevens

Linus Torvalds announced 2.6.2, or the "Feisty Dunnart", saying, "I just pushed out the BK trees, and the tar-ball/patches are going out as I write this, for Linux 2.6.2. The honor of naming it goes to Gernot Heiser, for reasons that are largely alcoholic, I suspect. Good job! The changelog from -rc3 mainly contains some ppc64 updates." Ian Soboroff replied:

For the benefit of those of you who, like me, didn't know what a dunnart is, from http://library.thinkquest.org/28994/dunnart.html:

There are ten species of dunnart. Some of them are the common dunnart, white-footed dunnart, and the Darling Downs dunnart. There is also the fat-tailed dunnart. They are called the marsupial mouse and are usually 10 to 16 cm. long.

They live in Australia and New Guinea. These marsupial mice live in deserts and rainforests and eat grasshopppers, spiders, lizards, mice and small animals.

All dunnarts are fearless and will protect themselves if they are scared or threatened. They all have litters of up to 10 babies about 3 to 4 times a year.

The fat-tailed dunnart is the smallest and has soft, fine, gray or black fur. They also have large ears and thick tails with short, stiff hairs. The dunnart stores all its fat in its tail.

According to that third paragraph, we need to up our release schedule a bit.

Alastair Stevens noticed that in the kernel Makefile, "Feisty Dunnart" was actually assigned to a real variable used for version numbering. John Bradford remarked, "There was some discussion on the list about dropping version numbers altogether during 2.7: http://marc.theaimsgroup.com/?l=linux-kernel&m=107174577415393&w=2."

11. Providing Open Firmware Paths In SysFS

3 Feb 2004 - 5 Feb 2004 (14 posts) Archive Link: "[PATCH] PCI / OF linkage in sysfs"

Topics: FS: sysfs, PCI, Power Management: ACPI, USB

People: Benjamin HerrenschmidtLinus TorvaldsGreg KHAndrew Morton

Benjamin Herrenschmidt said to Andrew Morton and Greg KH:

This patch adds a "devspec" property to all PCI entries in sysfs that provides the full "Open Firmware" path to each device on PPC and PPC64 platforms that have Open Firmware support.

For various reasons, the OF path is and will still be different than the sysfs path, and userland needs the OF path for various things, ranging from bootloader setup to XFree needing to access some OF properties provided by the graphic card F-Code driver, etc...

The "devspec" name is what we already use for "macio" type devices, it doesn't clash with anything else.

If you are happy with it, please apply (independently of the rest of the PowerMac patch), I need that to fix various things in XFree (among others), so it would be nice to have it in by 2.6.3 final

Linus Torvalds didn't like this approach, saying:

Wouldn't it make more sense to go the other way? Ie have the PCI devices be pointed to from the OF paths?

I'd prefer to avoid having OF-specific files in a PCI directory. That just leads to inherently unportable user mode stuff. In contrast, having the OF directory entry that points to the hardware (PCI) entry makes perfect sense.

Greg suggested, "Or, if you really want to be able to get the OF info from the pci device in sysfs, why not create a symlink in the pci device directory pointing to your OF path in sysfs? That would seem like the best option." But Linus replied:

Where does this stop? Do we start doing the same for all different kinds of buses, and all kinds of firmware?

In other words, instead of having <n> different buses all know about <m> different kinds of firmware information that they really have nothing else to do with, it's much better to just have the <m> different kinds of firmware information export their own information.

It just sounds _wrong_ to have the PCI layer have knowledge of OF. It has nothing to do with OF. For OF information, you should go to the /sys/of tree, which has the information that OF knows about (which may, of course, then include the information about PCI devices).

Greg saw the sense in this, but Benjamin said:

I don't quite agree... There are cases for example (USB, Firewire) where we could construct an OF path to be used by the bootloader setup without having the OF information in the first place (for devices that weren't plugged during boot typically). I do no intend to go that way for 2.6 though.

In both cases, we don't "have" the information.

OF doesn't have informations about the linux PCI layout (bus numbering can be different between OF and linux for example) and PCI doesn't have information about OF (except that on ppc64, pci_dev->arch_data points to the OF node).

However, the arch code provides a routine that can provide that mapping PCI -> OF (and in _that_ direction, there is one to go the other way around, but I hate it, it's not very reliable at the moment, though I could rewrite it..., and on ppc64, this is the most efficient way too).

It's just about providing a pointer to OF node, not actual informations out of the device-tree...

Linus replied:

Ok. Fair enough.

I think that I personally would be a lot happier with the situation if it wasn't that PCI had magic knowledge about OF in particular. In other words, you'd likely be able to sell me on an idea where the PCI layer just knows about "let the firmware install a few files here", but is totally firmware-agnostic per se.

In other words, you migth just rename the "OF" functionality as "platform" functionality, and add dummy (empty) platform handlers for the other platforms (eg BIOS/EFI whatever). Maybe some day EFI will want to have a similar pointer..

So while I'd hate to have the PCI layer start having to learn details of all the platforms out there, I don't think it's necessarily wrong that the PCI layer knows about the _concept_ of a platform, as long as it doesn't get too specific.

Benjamin asked, "What about adding a pcibios_add_platform_entries(device) called by pci_sysfs then ? By default an empty inline on asm/* and on PPC, I can add my devspec without having OF-aware code in drivers/pci" . Linus said this would be fine. In his same post, Benjamin also asked if the name "devspec" were OK, because it wasn't too late to change all occurrences before folks started to use it. Linus replied:

I have to admit that "devspec" doesn't seem to do much for me, but I don't think we should call it "firmware", since that would (to me) be more about the firmware of the _device_ rather than the platform.

Maybe just "platform-data" or something. But if "devspec" has magic meaning on a Mac, and since this would be inherently platform-specific _anyway_, I don't actually see any reason to not use "devspec".

On some platforms, we might have multiple different entries (eg on a PC we might have pointers to ACPI data, to PnP data and to EFI data, all at the same time. I hope we never will, but maybe there would be reason for it). That would argue _against_ a "generic" name like "platform", and for something that is actually very much specific to the kind of data it points to (eg "of-data" rather than "platform-data").

End result: I don't think we much care about the name. Whatever makes you happy. As long as the source code is clean and something like "pcibios_add_platform_entries()" at least makes that come true.

There was no further debate, and the discussion petered out quickly.

12. Some Kernel Release History

4 Feb 2004 - 6 Feb 2004 (2 posts) Archive Link: "Kernel releases 0.01 - 2.6.2"

People: Bill Davidsen

Terry Vessels created a couple of pages listing the history of as many Linux kernel releases as he could track down. He offered an HTML (http://edge-op.org/files/kernel-releases.html) version and a plain text (http://edge-op.org/files/kernel-releases) version. Bill Davidsen said, "Thanks for the timeline, may it continue! I can't believe how long I have run machines once they became stable... my last 1.2.13 machine was taken down on Y2k-eve, I still have a 2.1.106 machine running, and a 2.0.33 machine was upgraded to RHEL-3.0 early this year. Speaks well for stability that machines without security issues can just run virtually forever."

13. forcedeth Network Driver Version 0.23 Submitted

4 Feb 2004 - 5 Feb 2004 (2 posts) Archive Link: "[PATCH] [2.4] forcedeth network driver"

People: Carl-Daniel HailfingerJeff GarzikManfred Spraul

Carl-Daniel Hailfinger said:

attached is the current version (0.23) of forcedeth, a network driver for nForce{,2,3} chipsets which are fairly common today. So far, the only support for nForce chipsets has been a binary-only driver from NVidia.

The previous patch I sent generated some criticism from Jeff Garzik et al. which has been addressed in the current version. The current version has been posted for review twice and nobody has complained about it for more than a week.

This driver has received testing by over 200 people on nForce1, nForce2 and nForce3 chipsets and has already been integrated into 2.6. Before that, it has been in -mm for a few weeks. We currently don't have any unresolved bug reports.

Credits for the driver go to:
Andrew de Quincey: Writing a spec for the chipset
Carl-Daniel Hailfinger: Co-author of the spec, driver fixes
Manfred Spraul: Writing the driver

Jeff Garzik replied, "I'll send to Marcelo... but it's up to him whether he will include it in 2.4.25-pre ot 2.4.26-pre. He said he's planning on releasing 2.4.25-rc soon..."

14. uClinux Update

4 Feb 2004 (1 post) Archive Link: "[PATCH]: linux-2.6.2-uc0 (MMU-less fixups)"

People: Greg UngererRandy DunlapDomen PuncerRussell King

Greg Ungerer said:

An update of the uClinux (MMU-less) fixups against 2.6.2. A few new things, and some previous patches now merged.

http://www.uclinux.org/pub/uClinux/uClinux-2.6.x/linux-2.6.2-uc0.patch.gz

New in this patch:

mcfserial tiocmget/set fixup Russell King
mcfserial cleanup Randy Dunlap/Domen Puncer
remove unused CONFIG_LEDMAN Randy Dunlap/Domen Puncer
68328 frame buffer fixups Georges Menie
m68k support for cs89x00 Georges Menie

15. Linux 2.6.2-mm1 "Geriatric Wombat" Released

5 Feb 2004 - 7 Feb 2004 (44 posts) Archive Link: "2.6.2-mm1 aka "Geriatric Wombat""

Topics: Version Control

People: Andrew MortonRussell KingJeff GarzikLuis Miguel GarciaMatthias UrlichsLuis Miguel

Andrew Morton announced:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.2/2.6.2-mm1/

Russell King asked:

Does this include the changes to all those PCMCIA net drivers which Jeff has had for a while from me?

I'd like to get those patches into mainline so I can close bugme bug 1711, but I think Jeff's waiting for responses from the individual net driver maintainers first. ;(

Jeff Garzik confirmed that the release did contain Russell's patches; and added that he hadn't been waiting for the net driver maintainers, he was "just waiting for 2.6.2 to be released. The first post-262 batch has been merged, am now sending the second batch. Yours is in the third batch :)"

Luis Miguel Garcia also asked, "Andrew, do you know if this acpi pull down has nforce support fixed? Or perhaps it's even unnotified to the acpi team?" Andrew said his release didn't appear to have the fix, and he didn't know if the developers knew about the problem. Arjen Verweij asked Luis for more information on the problem, but there was no discussion.

Elsewhere, Matthias Urlichs remarked, "Just for general elucidation: this tree now touches 1854 files, or slightly more than ten percent of the kernel source, with roughly 3500 changes, packaged in 1500 Bitkeeper changes and/or individual patches. Feel free to draw unwarranted conclusions from these numbers...."

16. Linux 2.4.25-rc1 Released

5 Feb 2004 - 6 Feb 2004 (1 post) Archive Link: "Linux 2.4.25-rc1"

Topics: Big Memory Support, FS: XFS

People: Marcelo Tosatti

Marcelo Tosatti released 2.4.25-rc1, saying:

Here goes the first release candidate.

It contains mostly networking updates, XFS update, amongst others.

This release contains a fix for excessive inode memory pressure with highmem boxes. Help is specially wanted with testing this on heavy-load highmem machines.

17. FUSE (Filesystem In User Space) Update

5 Feb 2004 - 6 Feb 2004 (5 posts) Archive Link: "[ANNOUNCE] Filesystem in Userspace (FUSE) 1.1 stable version"

Topics: FS: NFS, Samba

People: Szeredi Miklos

Szeredi Miklos announced FUSE 1.1, saying:

This release adds support for the 2.6 Linux kernel series. Other new features include support for exporting FUSE filesystems over NFS, read efficiency improvements, automatic lazy unmounting, the addition of the fsync call, plus minor bugfixes and cleanups.

Download from:

http://sourceforge.net/project/showfiles.php?group_id=21636&package_id=31956&release_id=214856

About:

FUSE is a combination of a kernel module and a userspace library that makes the creation of filesystems in userspace very easy. A "Hello World" filesystem implementation is just 59 lines long (excluding empty lines and comments).

There are currently a number of applications using FUSE in the following categories: exporting internal state of devices (OWFS, SieFS), exporting existing userspace virtual filesystems (KIO - FUSE gateway, AVFS), network filesystems (SMB for FUSE, FunFS), encrypted filesystems (EncFS, PhoneBook), exporting internal data of applications (Run Time Access). For more info about these see 'Filesystems' in the distribution.

In addition to the native C API, FUSE has bindings for a number of other languages: Perl, Python, Java and C++.

FUSE was designed with the following goals in mind: very simple userspace API, generic, efficient (but still simple) kernel API and ability for non-root users to create and mount filesystems securely.

Future plans:

I plan to submit the next version (with a revised user - kernel interface) for inclusion into the 2.6 and/or 2.7 kernels. Still to do is a modification of the mount syscall to allow non-root users to mount FUSE filesystems (currently done with a suid-root helper program).

18. Status Of INI9100U Driver In 2.6.2

5 Feb 2004 (2 posts) Archive Link: "2.6.2 and INI9100U"

People: Christoph Hellwig

Wojciech Cieciwa asked why the INI9100U driver was marked as broken in 2.6.2, since it seemed to work perfectly for him; Christoph Hellwig explained, "There's no error handling, so as soon as you hit some kind of bus error you're screwed."

19. New rcu_barrier() Interface Possibly Useful For ReiserFS

5 Feb 2004 (3 posts) Archive Link: "[PATCH] RCU barrier"

Topics: FS: ReiserFS

People: Dipankar SarmaNikita Danilov

Dipankar Sarma said, "This patch introduces a new interface - rcu_barrier() which waits until all the RCUs queued until this call have been completed. Nikita asked for this quite a while ago for reiser4 jnodes. Sorry Nikita, if you are still using RCU in new reiserfs, you don't need to use your own logic for this now. Just call rcu_barrier() during umount. If Nikita or other users use it, then I would like to push for including this." Nikita Danilov said, "Yes, we are still using RCU in the reiser4 (bravely). rcu_barrier() would allow us to get rid of some really ugly code." Dipankar said to let him know if his patch would do the trick, and if so he'd push for inclusion.

20. HFS+ Driver Update For 2.6.1; 2.6 Inclusion Policies

5 Feb 2004 - 6 Feb 2004 (7 posts) Archive Link: "Re: HFSPLus driver for Linux 2.6."

People: Dylan GriffithsAndrew MortonMatthias UrlichsBenjamin HerrenschmidtRoman Zippel

Dylan Griffiths said:

Hi. I've just recently cleaned up a copy of the HFS Plus driver to apply to 2.6.1. I'd like to submit it for inclusion in your -mm series, so I don't have to keep maintaining something that's out of tree. HFS+ support is one of those things I'd like to see in 2.6 soon, so things like my Mac iPod and friend's HFS+ formatted firewire drives will work on my Linux machines :)

I don't remember where I grabbed this driver, I only know it's much more current than the one at http://sourceforge.net/projects/linux-hfsplus. I've used it a lot for my iPod on 2.4, and have had success with it on 2.6.

Andrew Morton said:

Sorry, that's a showstopper. We need to understand who the maintenance team is, and evaluate their preparedness to maintain this code long-term.

We don't want to be adding yet another rarely-used filesystem which has no visible maintenance team.

Matthias Urlichs said, "That probably was http://www.ardistech.com/hfsplus/. Their latest release is from mid-December." He added, "The Mac-m68k and the Mac-PPC people would probably disagree about the "rarely-used" part. I do agree that adding a filesystem, no matter how widely used, without at least somebody to liaise between the kernel people and the authors is a bad idea." Close by, Benjamin Herrenschmidt put in:

It's a not-that-rarely used filesystem actually :) Been in my tree for a few monthes and it's used by pmac users either for iPod's or for accessing the MacOS X partitions.

It's written & maintained by Roman Zippel, and the latest snapshot is available at http://www.ardistech.com/hfsplus/ but you probably want to ask Roman if it's really the latest version before merging :)

One thing we absolutely need too is a port of Apple's fsck for HFS+, currently, the driver will refuse to mount read/write a "dirty" HFS+ filesystem to avoid corruption, but that means we have to reboot MacOS to fsck it then... But that limitation shouldn't prevent merging it.

I suppose it may be good to also merge Roman's cleanup/rewrite of the old HFS filesytem...

21. Linux Test Project Release For February

6 Feb 2004 (1 post) Archive Link: "[ANNOUCE] Linux Test Project February Release"

People: Marty RidgewayErik Andersen

Marty Ridgeway said:

The Linux Test Project test suite <http://www.linuxtestproject.org> has been released. The latest version of the testsuite contains 2100+ tests for the Linux OS. Our web site also contains other information such as: test results, a Linux test tools matrix, technical papers and HowTos on Linux testing, and a code coverage analysis tool.

Developers from the Linux Test Project co-authored the whitepaper, "Putting Linux Reliability to the Test". This article documents the test results and analysis of the Linux kernel and other core OS components, including everything from libraries and device drivers to file systems and networking, all under some fairly adverse conditions, over a period of 60 days. You can find the paper at: http://www.ibm.com/developerworks/linux/library/l-rel

Release Highlights:

We encourage the community to post results to ltp-results@lists.sf.net, and patches, new tests, or comments/questions to ltp-list@lists.sf.net.

22. Linux 2.6.3-rc1; Status Of SysFS Support

6 Feb 2004 - 9 Feb 2004 (21 posts) Archive Link: "Linux 2.6.3-rc1"

Topics: Disks: SCSI, FS: sysfs, Framebuffer, Kernel Release Announcement, Sound: ALSA

People: Linus TorvaldsAlexander ViroKevin O'ConnorGreg KH

Linus Torvalds announced Linux 2.6.3-rc1, saying:

Ok, this is another big merge of a number of pending patches, although to some degree the patches have now moved "outwards" from the core, and most of them are in driver land.

There's a lot of network driver updates (have been in -mm and Jeff's testing trees for a while), and Al Viro has been fixing up not just network drivers, but also cursing over parport interfaces ;)

Andrew's patches are all over, from fixing warnings with new versions of gcc to merging things like the ppc updates he had in his tree, and everything in between.

On and a big ALSA update, along with SCSI updates (big qla update, for example).

So let's calm down and make sure all the updates are ok.

Alexander Viro said:

One note: please, please, let's put a moratorium on sysfs-related patches that didn't go through review. We are just getting netdev situation in the main tree under control. It took nearly half a year (if not more). And now we've got *exact* *copy* of the change that had started that mess - this time in fbdev. Sure, there's fewer fbdev drivers, so it shouldn't take that long. But then it's not 2.5 anymore...

If you are doing any sysfs integration - *fix* *lifetime* *rules* *first*. You can do that in a way that will avoid breakage or need to revisit the drivers when kobjects get embedded - just have your my_subsystem_release() defined as kfree() and on the last step replace its body with kobject_put(), moving the actual freeing into ->release().

Even if you are sure that you can fix all drivers in one go, there's no need to turn the entire series into "must merge at once" monster - if nothing else, reordering it that way will make testing easier. Sigh...

Kevin O'Connor replied:

There appears to be a lot of developer activity concentrated on getting sysfs support in various parts of the kernel, and this inevitably leads to a reworking of kernel object lifetime rules. I have to wonder if making these lifetime changes is really a good idea.

Sysfs appears to be mainly used for exporting various adhoc pieces of information and occasionally for getting various tuning input. This functionality is generally ancillary to the main purpose of the subsystems/drivers that use sysfs. It seems backward to me that the lifetime rules of an object should be dominated by this ancillary functionality.

So, my question - is it really a good idea to rework much of the kernel object lifetime rules just to support sysfs?

Greg KH replied:

At this point in time, in the stable kernel series, I say no.

That is why I created the class_simple interface, which allows developers to be able to export data through sysfs (like the dev_t data), without having to change their lifetime rules at all.

Now when 2.7 starts up again, that's the proper time to be changing this kind of stuff to work "properly". Until then, lets just live with the lifetime rules that we have (if they work, and almost all of them seem to).

And remember, I'm the person who really _wants_ to see all of this stuff fixed up properly...

23. Linux 2.0.40 "Moss-Covered Tortoise" Released

8 Feb 2004 (1 post) Archive Link: "[ANNOUNCE] Linux-kernel 2.0.40 aka ``The Moss-covered Tortoise''"

Topics: Compression, FS: ext2

People: David Weinehall

David Weinehall said:

Hereby I wish to announce Linux-kernel v2.0.40, aka ``The Moss-covered Tortoise''. This release fixes several remote information-leaks, a few local exploits, possible group descriptor corruption for ext2fs, a few network related issues, a few SUS/LSB compliance issues, and various other minor changes. A complete changelog can be found at the same places the kernel itself can be downloaded.

This upgrade is of medium urgency, and is a recommended upgrade if you experience problems. This kernel is only maintained, not developed, and hence, if you miss support for hardware/software or any feature, then you should consider upgrading to either the latest v2.4.xx kernel or the latest v2.6.xx kernel.

The kernel can be found at:

ftp.xx.kernel.org (ftp://ftp.us.kernel.org) (where xx is your country-code)

Complete tarballs (compressed with gz and bzip2 respectively):

/pub/linux/kernel/v2.0/linux-2.0.40.tar.gz (http://ftp.kernel.org/pub/linux/kernel/v2.0/linux-2.0.40.tar.gz)
/pub/linux/kernel/v2.0/linux-2.0.40.tar.bz2 (http://ftp.kernel.org/pub/linux/kernel/v2.0/linux-2.0.40.tar.bz2)

As a patch to be applied on top of the v2.0.39 kernel-tree (compressed with gz and bzip2 respectively):

/pub/linux/kernel/v2.0/patch-2.0.40.gz (http://ftp.kernel.org/pub/linux/kernel/v2.0/patch-2.0.40.gz)
/pub/linux/kernel/v2.0/patch-2.0.40.bz2 (http://ftp.kernel.org/pub/linux/kernel/v2.0/patch-2.0.40.bz2)

Note that some mirrors might not keep both compression-formats.

 

 

 

 

 

 

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.