The 2.6.0 "must fix" list [LWN.net]

One of the important steps in getting a 2.6.0 release out the door is creating an organized list of crucial outstanding issues. For this development cycle, that job seems to have fallen to Andrew Morton, who has posted the first version of a "must-fix" list for 2.6.0. It's a long list, even though it does not include routine bugs kept in the kernel bugzilla system.

Many of the outstanding issues can be found in the block I/O subsystem - not surprising, considering how much things have changed there. RAID (especially RAID0) still has some problems with large requests. CD burning can still hang. IDE tagged command queueing still does not work correctly; the solution here may be to just take it out for 2.6. Work in I/O schedulers is still ongoing; some of the schedulers could use some improvement, and there needs to be a mechanism for choosing between them. The floppy driver is still bug-ridden. And the IDE subsystem still has a long list of things that need to be fixed.

In the filesystem arena, ext3 still lacks a working data=journal mode. ext3 also still uses the big kernel lock, with significant work required for its removal. There are race conditions with asynchronous I/O and truncate() which can corrupt filesystems. NFS still has a number of outstanding issues.

Networking has a potential deadlock for UDP applications. IPSec has a number of outstanding problems including a substandard key management implementation, "mysterious TCP hangs," the lack of an MPLS implementation, and incomplete IPv6 support.

In the kernel core, there are still complaints about poor interactive response out of the new scheduler. The memory overcommit accounting is not as accurate as it needs to be. There are still some issues with the reverse-mapping VM (and the later object-based rmap patch) which can lead to performance problems in some situations.

Then, there is still the 64-bit dev_t work; "...with the recent rise of the neo-viro I'm not sure where things are at."

Power management still needs quite a bit of work. Much of the power management core code remains to be merged, there needs to be a user-space interface for power state transitions, and quite a bit of device support work needs to be done. Restoration of video state appears to be particularly tricky. There is also an effort afoot to rewrite the software suspend code in a better way.

An issue which should not be overlooked is the large number of fixes from the 2.4 series which have not yet made it into 2.5. Those all need to be pulled together, ported forward, and merged.

The above is a summary; the full list is rather longer. But, then, these lists are always long until the release gets close.

(Log in to post comments)

The 2.6.0 "must fix" list

Posted May 1, 2003 3:48 UTC (Thu) by proski (subscriber, #104) [Link]

I'm surprized that the framebuffer support is in such bad shape, in particular Matrox framebuffer. The fixed Matrox framefuffer driver has been available for months. The latest patch is against Linux 2.5.68, yet it's not in 2.5.68-bk10. Worse yet, the patch doesn't apply to 2.5.68-bk10 because there were minor changes in the code including the Matrox driver that still doesn't compile.

For crying out loud, what's the point in keeping and changing broken driver in the tree when the fix is around? If the new driver is unstable, mark it as experimental (framebuffer support is already experimental on i386). If it needs work, put FIXME inside.

When I posted my patches to other subsystems, sometimes they would be in the bk snapshot next morning. Yet is takes months to propagate compile fixes in the framebuffer code.

I hope that Andrew Morton's attention to the problem will make framebuffer maintainers more willing to work with those who do the actual coding.

Matrox framebuffer

Posted May 1, 2003 15:02 UTC (Thu) by bart (guest, #466) [Link]

Petr Vandrovec (the author of the matrox framebuffer patch to which you refer) believes the patch isn't ready for submission yet. See his mail to lkml.

Matrox framebuffer

Posted May 1, 2003 15:49 UTC (Thu) by proski (subscriber, #104) [Link]

Indeed. Sorry, I misinterperted the situation.

The 2.6.0 "must fix" list

Posted May 8, 2003 12:15 UTC (Thu) by MikeDiack (guest, #3036) [Link]

I know that 2.4.0 had a huge to do list that was still unresolved when 2.4.0-test[n] and 2.4.0 appeared? i.e. the big list didn't preclude the release.
Does anyone have a feeling if we are in a similar situation here, or are we genuinely miles from a 2.6.0. Obviously the I/O stuff and IDE needs resolution before 2.6.0, but ... the rest?

Mike