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

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)

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:

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

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:

doesn't apply anymore

is buggy as your follow on message stated

I don't think it's really needed.

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

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

Various fixes. Nothing stands out.

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

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.

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.

migrate_all_tasks() called with machine stopped, and migrates
kernel threads as well.

cpu.c fires off a thread to do the dirty work: it schedules with
interrupts still disabled on dead cpu.

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.

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.

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.

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.

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

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.

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:

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

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.

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

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

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

Various random fixes.

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

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.

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

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

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.

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

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

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

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

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.