Version 3 of the 2.6 "must-fix" list
been posted. The list has seen additions and removals, but is not getting
a whole lot shorter.
On May 14, a number of developers met via IRC to discuss this list; the IRC log is available for those who would like
to see how the discussion went. A detailed writeup will be made available;
briefly, the main points discussed were:
- The TTY drivers need a lot of work; there are lots of locking and
other problems. Some of the problems are denial-of-service holes, so
fixes will have to be backported to 2.4 as well. It's on Alexander
- BIO splitting (with the ability to split on non-page boundaries) is
still needed, to fix the RAID problems if nothing else.
- The input layer also still has problems, including locking and
difficult configuration options.
- Merging the ARM code, including a bunch of drivers that could,
perhaps, be useful beyond the ARM architecture. The real question
there is where they should go in the tree...hardly a 2.6 show
- CardBus problems; this is a locking issue again.
- Lots of framebuffer work remains; it has been proceeding slowly.
- SCSI: the discussion was mostly about which drivers should be merged
and/or need fixing.
- Races involving direct I/O and the truncate() system call
which can destroy filesystems. This one looks hard to fix, but
something needs to be done. In the worst case, direct I/O could be
disabled for regular files, but nobody likes that option.
- Some scheduling problems remain; Ingo Molnar has patches, but nobody
is sure how many of the problems those patches fix.
- Networking: the big problem is one where TCP sessions occasionally
hang. More traces of hung connections will be needed to track this
- Process accounting is broken for 32-bit user IDs. This one looks like it can
be fixed using some padding in the accounting record structure. Alan Cox
(conveniently absent) was nominated to do the fix.
- The 1000HZ clock on the i386 architecture is creating some timekeeping
problems that need to be fixed. In the worst case, the clock
frequency would have to go back to 100, but there should be a better
- 64-bit dev_t: Al Viro wants to do quite a bit of work, still,
with device number allocation (especially for char devices) and
Andries Brouwer is still looking for problems in ioctl()
calls. It was asked whether this work could be decoupled from the
size change; as was pointed out, going ahead and changing the size of
dev_t would make many of the problems more apparent. The
/proc/devices file poses some interesting compatibility
problems in the new device number scheme.
The discussion did not get through the entire list before time ran out (the
Europeans were getting seriously tired, since it was after midnight there,
and even kernel hackers begin to slow down about then). Another discussion
next week is likely.
to post comments)