The 2.3.x "Things To Fix" List

Johan Jonasson writes "Alan Cox has posted the first draft of the 2.3.x "Things to fix" list. Also known as "the stuff that has to be taken care of before 2.4 can come out". "

Comments

Bugs by Architecture?

[slpalmer]

It would be a great benefit (to me at least) to see this list of bugs by architecture. If I want to know what's going on with the Alpha Port I have to research almost every bug to find which ports it affects, before I can consider spending time trying to fix something.

Some things I'd -like- to see in 2.3.x

[jd]

• The S/390 patches, from 2.2.x
• Reiserfs
• Ext3
• Procfs
• Softnet
• EITHER Posix ACL, OR Trustees
• Itanium support (I -know- it exists, somewhere)
• Transmeta support (C'mon, Linus, don't keep us in suspense! It's bad for the arteries. :)

Some things I'd -like- to see, for 2.5.x:

• Fixed QNS, NTFS and HPFS filing system support
• Better Configuration Documentation (missing from too many options)
• Any extensible network addressing protocol
• Better support for SMP
• Multi-protocol tunneling
• Better co-operation with the various microkernel efforts (eg: L4Linux)
• All kernel bugs fixed
• All buffer overflows removed
• Peace on Earth and Goodwill to Men

Journaling filesystem

[Poe]

It seems a shame that none of the journaling filesystems that are in the works are going to be ready in time for 2.4 (i.e. ext3, ReiserFS, or XFS) (unless I lost one of them somewhere in the alphabet soup)

There was some talk of these on Kernel Traffic, but apparently to no avail.

This is still one area that NT kinda shows linux up. (though there are plenty of bones to pick with NTFS, don't get me wrong) Not only that, but it's a neat, useful idea that adds much and takes nothing away. (I'm sure you'll be able to use ext2 'till the earth falls into the sun.)

Re:QA work for linux

[Christopher B. Brown]

This is not all that interesting work, in some ways, but certainly useful stuff.

The necessary methodology involves automating execution of QA tests. You don't want to have to run 'em all by hand...

Approach:

• For each test, X, cd /usr/src/qa/tests/X
• make clean; make test

  This compiles a C program that exercises some facility of the system.

  The program drops output into a local file in the directory, as well as to a central results DB in /usr/src/qa/results , where entries are keyed by test, by date, and by kernel version.

  The notable result is a Pass or Fail value.

• A script runs through all the directories, running each test.

  It would be good if a "success" result caused the test program to create the file success, so that one could run through, after a patch, and "merely" use make success to rerun failed tests.

• Every time you locate a bug, you create a test.
• Every time you find behaviour that ought to be, you create a test.

This is more-or-less how one does regression testing with things like compilers. Tests that run with the kernel would be equally valuable.

If you build a reasonably intelligent infrastructure, and are accepting of regression tests, you'll come to know more about how the kernel works than you ever wanted to know...