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.

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".

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
with the source rpm at:
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

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

Major changes from the 014 version:

• we finally look up the chain of sysfs device entries trying to match all devices in the chain for each rule.

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:

• udevsend - sends the hotplug message to the udev daemon
• udevd - the udev daemon, gets the hotplug messages, sorts them in proper order, and passes them off to the udev program to act apon them.
• udev - still the same.

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.

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

• doesn't apply anymore
• is buggy as your follow on message stated
• I don't think it's really needed.

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

• From now on, -mm kernels will contain the latest contents of:

  Linus's tree:	linus.patch
  The ACPI tree:	acpi.patch
  Vojtech's tree:	input.patch
  Jeff's tree:	netdev.patch
  The ALSA tree:	alsa.patch

  If anyone has any more external trees which need similar treatment, please let me know.

• Various fixes. Nothing stands out.

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:

• Support for HighMem (Up to 4G), SMP (SMP is currently only supported under 2.4; 2.6 support should not be far away.) and preemptive kernels.
• Support for any number of swap partitions and/or files.
• Full asynchronous I/O and readahead for synchronous I/O for maximum throughput.
• Image compression (LZF and GZIP - the former is very fast and highly recommended).
• Support for saving a full image of your memory, resulting in a fast, responsive system after resuming.
• Support for plugins: data transformers (compression, encryption) and new storage backends (NFS support is planned).
• Nice user interface (Bootsplash (http://www.bootsplash.org) compatible;
• The ability to specify a maximum image size;
• The ability to cancel a suspend by pressing Escape (for security, this can be disabled).
• Speed and reliability. Software Suspend 2.0 has been extensively tested in a variety of configurations over many months. It is not guaranteed to be perfect, but bugs found will be hunted and fixed quickly.

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:

• DRI support is lacking power management support under 2.4 & 2.6.
• AGP support under 2.6 is partially implemented.
• USB support under 2.4 and 2.6 is lacking.
• SMP support is currently 2.4 only.
• Other drivers have varying degrees of power management support.
• There is currently no support for discontig memory.
• Suspend currently requires the PSE extension (check /proc/cpuinfo).
• Highmem >4GB is currently not supported.
• SMP currently suffers from lost interrupts during resuming
• 2.6 does not currently flush caches properly before powering down.

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...

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? ;-)

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

• I added a few late-arriving patches. Usually this breaks things.
• Added a few external development trees (USB, XFS).
• PNP update

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:

• drivers/base/cpu.c: Add an "online" attribute.
• drivers/scsi/scsi.c: drain the scsi_done_q into current CPU on CPU_DEAD
• fs/buffer.c: release buffer heads from bh_lrus on CPU_DEAD
• linux/cpu.h: Add cpu_down(). Add hotcpu_notifier convenience macro. Add cpu_is_offline() for when you know a cpu was (once) online: this is a constant if !CONFIG_HOTPLUG_CPU.
• linux/interrupt.h: Add tasklet_kill_immediate for RCU tasklet takedown on dead CPU.
• linux/mmzip.h: keep pointer to kswapd, in case we need to move it.
• linux/sched.h: Add migrate_all_tasks() for cpu-down. Add migrate_to_cpu for kernel threads to escape. Add wake_idle_cpu() for i386 hotplug code.
• kernel/cpu.c: Take cpucontrol lock around notifiers: notifiers have no locking themselves. Implement cpu_down() and code to call sbin_hotplug.
• kernel/kmod.c: As a bound kernel thread, take care of case where thread is going down, before keventd() CPU_OFFLINE notifier can return.
• kernel/kthread.c: Same as kmod.c, take care of race where CPU goes down and we didn't get migrated.
• kernel/rcupdate.c: Move rcu batch when cpu dies.

• kernel/sched.c: Add wake_idle_cpu() for i386 hotplug.

  Check everywhere to make sure we never move tasks onto an offline cpu: we'll just be fighting migrate_all_tasks().

  Change sched_migrate_task() to migrate_to_cpu and expose it for hotplug cpu.

  Take hotplug lock in sys_sched_setaffinity.

  Return cpus_allowed masked by cpu_possible_map, not cpu_online_map in sys_sched_getaffinity, otherwise tasks can't know about whether they can run on currently-offline cpus.

  Implement migrate_all_tasks() to push tasks off the dying cpu.

  Add callbacks to stop migration thread.

• kernel/softirq.c:

  Handle case where interrupt tries to kick softirqd after it has exited.

  Implement tasklet_kill_immediate for RCU.

  Code to shut down ksoftirqd, and take over dead cpu's tasklets.

• kernel/timer.c:

  Code to migrate timers off dead CPU.

• kernel/workqueue.c:

  Keep all workqueue is list, with their name: when cpus come up we need to create new threads for each one.

  Lock cpu hotplug in flush_workqueue for simplicity.

  create_workqueue_thread doesn't need name arg, now in struct.

  Lock cpu hotplug when creating and destroying workqueues.

  cleanup_workqueue_thread needs to block irqs: can now be called on live workqueues.

  Implement callbacks to add and delete threads, and take over work.

• mm/page_alloc.c:

  Drain local pages on CPU which is dead.

• mm/slab.c:

  Move free_block decl, ac_entry and ac_data earlier in file.

  Stop reap timer on as cpu goes offline.

  Neaten list_for_each into list_for_each_entry.

  Free cache blocks and correct stats one CPU is dead.

  Make reap_timer_fnc terminate if cpu goes offline.

• mm/swap.c:

  Fix up committed stats and drain lru cache when cpu dead.

• mm/vmscan.c:

  Keep kswapd on cpus within node unless all CPUs go offline, and restore when they come back.

  Record kswapd tasks for each pgdat upon creation.

• net/core/dev.c:

  Drain skb queues to this cpu when another cpu is dead.

• net/core/flow.c:

  Call __flow_cache_shrink() to shrink cache to zero when CPU dead.

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...

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.

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.

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

• There is a debug patch in here which detects when someone calls i_size_write() without holding the inode's i_sem. It generates a warning and a stack backtrace. We know that XFS generates such a trace. It will turn itself off after the first ten warnings. Please don't report the XFS case.
• Added the CPU hotplug code.
• This kernel is currently broken on ppc64. Something to do with the sched-domains patch although at this stage we do not know whether the problem lies with that patch or with the ppc64 code.
• A big Altix update
• Latest versions of various other developers' trees. See below for details.
• Various other fixes

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.

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.

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

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.

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).

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...

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.

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.

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

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

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

• Merged some page reclaim fixes from Nick and Nikita. These yield some performance improvements in low memory and heavy paging situations.
• Various random fixes.

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. ;(

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.

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).

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.

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.

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...

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:

• Code cleanups by Erik Andersen, Glen Foster, Jay Turner, and Ming Gao.
• Improvements to allow tests to build and execute under more environments and distributions.

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.

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.

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...

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?

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...

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 (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
/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
/pub/linux/kernel/v2.0/patch-2.0.40.bz2

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