Slashdot Mirror
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". "
← Back to Stories (view on slashdot.org)
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.
I know the feeling. I found Wrox's (whose stuff I generally dislike) Beginning Linux Programming to be generally excellent. Read it with a good C reference handy and you will go far, grasshopper. There are several docs in the LDP dealing with kernel dev and device drivers, as well.
illegitimii non ingravare
How about fixing NFS on SMP too. That's been broken ever since 2.2.13. It seems like Alan was working on it in September and then he just lost interest in it.
2.2.13 must be what - at least a month old ?
NFS on SMP is working JUST FINE on my SMP box, running 2.2.12 with the knfsd-1.4.7 patches. And it has been for about 2.5 months. Most of the knfsd patch functionality has been merged into the 2.2.14-pre tree, so 2.2.14 ought to be a fairly stable NFS branch, even for SMP users. At least for NFS version two, which is a fairly old standard.
If you are really interested, there is a separate mailing list for nfs users that has been posted to the kernel mailing list, and the user space utilities have been evolving from knfsd-1.4.7 to nfs-utils-0.15 or so. Linux nfs now has locking and everything. Still, you'd have to consider nfs on linux a real weakness compared to other Unices. NFS version 3 is still a pipe-dream for clients or servers, and version two is just now stabilizing in the 2.2 tree.
Some things I'd -like- to see, for 2.5.x:
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Anyone got any good suggestions for getting started on linux programming or hell any good suggestions for starting? I actually thought about taking some courses at night.
It seems almost redundant (no KT intended) to mention O'Reilly books as an excellent resource...anyway, if you're looking for some insight into the Linux kernel, O'Reilly's Linux Device Drivers book is very educational. At least for me it was. I've never worked on the kernel or device drivers for it and probably never will, but I found the book to be very informative nevertheless. BTW, I also am a Perl/PHP geek...not very fluent in C.
numb
I know it wouldnt be all that difficult to include generic softmodem support in the kernel, and that would REALLY make a lot of people happy (myself included). I wrote a mod for mine, but I'm not all that great at Kernel programming, and it has a habit of not working or crashing altogether. If it supported more devices (maybe better USB support as well), more people might consider linux over windows.
=======
There was never a genius without a tincture of madness.
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.)
Thank you for not thinking.
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
- A script runs through all the directories, running each test.
- 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.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.
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.
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...
If you're not part of the solution, you're part of the precipitate.
I also wish there had been more push for make Linux x86 a better database server platform. Limitations that get in the way are:
Another item is the ability to have multiple default routes and routing to the default route based on source ip address. Multi-homing on multiple Internet feeds just isn't any fun when all your outbound traffic goes through the same pipe regardless of where the request comes from.
Anyways, I look forward to the 2.5 developments. The 2.3 kernel series has been fun. :)
In a press release made yesterday, Suse announces that ReiserFS 3.5.12 (that's not the latest version) can now be downloaded from their site at ftp://ftp.suse.com:/pub/suse/i386/update/6.3/reise rfs/. It's not a final version and you won't get support for it (if you have bought Suse 6.3).
0 0/ or Suse's announcement at http://www.suse.de/de/news/news/kurzmeldungen/reis erfs.html (both in German, Babelfish may help).
See the Heise newsticker posting at http://www.heise.de/newsticker/data/ps-04.01.00-0
I come to slashdot for nerd news, not linux news.
Well, for one, it could be argued that if you go to a health-food store looking for 'food, not health food' you'll be sorely dissapointed. Slashdot is what it is...
For another, the articles are in categories; this one is in the category "Linux", denoted by the cute little penguin on graphical browsers, or the 'Linux' alt tag on text browsers. Given the context, a version number number alone doesn't leave much room for doubt.
Would you understand if a post claimed that Version 7 would be coming out next month? Version 7 of what? Who knows?
Well, if it were say, next to the Beos logo, I would assume it was version 7 of Beos. (just to choose an example at random, I don't know what version Beos is at). I guess if it were next to the Monty Python foot I might be confused...
Finally, you have a login. Take a look at your preferences and adjust accordingly.
San Francisco values: compassion, tolerance, respect, intelligence
I haven't heard much of a good argument against devfs.
/dev/ directory structure, true, but a method to write out changes and read them back in at boot would be very simple to implement. You lose anything in the buffer-cache if you power-off without sync'ing, but nobody complains about that. So that isn't the issue.
/dev/ directory is too big a change to swallow for some people. Some of those people are kernel hackers with demigod or higher status, so the change isn't going in.
devfs impacts every device driver in the kernel, true, but one assumes that if it is worthwhile, we can deal with that. Kernel-wide changes have been done before and will be again. And most of the changes have been done as patches by the devfs maintainer already. So that isn't the real issue.
devfs would add complexity to the kernel, but so does everything else that adds code. So that isn't the real reason.
You would lose persistance of the
In the end, it always comes down to "What we have now works fine, and we've done it this way forever, so why change?" The idea of replacing the
Too bad, really. I think devfs has a lot of merit to it.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
But if all you did was to patch the kernel a bit to fix a particular problem, it may be desirable to just run the tests that you figure are related to that change.
Rerunning the full suite overnight or on some other reasonable periodic basis to find problems that may have been introduced would be an obvious thing to do.
The real point is that if the test suite grows to 15MB of source code, and runs for 25 hours, you don't run the whole thing every time you make a little change. You run the parts that could conceivably be relevant. And run the whole thang once in a while.
Or perhaps have a daemon that grabs the latest kernel every time one is released, and runs it through regression.
That's not a concern until there's so many tests that they'll run for many hours...
If you're not part of the solution, you're part of the precipitate.