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)
(because we're lazy, the list is short, and because I want to eschew the 1stposters)
Multiwrite IDE breaks on a disk error
Poll on > 16000 file handles fails
Restore O_SYNC functionality
Merge the network fixes - there is a ton of backed up stuff to do asap
ISA DMA is no longer allocating correctly aligned data
vmalloc(GFP_DMA) is needed for DMA drivers
VM needs rebalancing
NFSD fixes for path walking to regenerate dentries
Fix eth= command line
Check O_APPEND atomicity bug fixing is complete
Protection on isize (sct)
Merge 2.2.13/14 changes
Get RAID 0.90 in
PAE36 failures
USB HID merge
Mikulas claims we need to fix the getblk/mark_buffer_uptodate thing gor
2.3.x as well
PIII/Athlon/MMX/etc acceleration merge from 2.2.x-ac
Merge arcnet update (DONE)
Fix SPX socket code
AHA152x isnt smp safe (FIXED)
NCR5380 isnt smp safe
isofs break on 4Gig disk (FIXED ?)
Finish 64bit vfs merges (stat64 etc) (DONE ??)
Make syncppp use new ppp code
Fbcon races
Fix all remaining PCI code to use new resources and enable_Device
Stackable fs ?? (Erez)
Get the Emu10K merged
Test PMC code on Athlon
Fix module remove race bug (-- not in open so why did I see crashes ??? --)
Per Process rtsigio
Maybe merge the ibcs emulation code
VFS?VM - mmap/write deadlock
initrd is bust
rw sempahores on page faults (mmap_sem)
kiobuf seperate lock functions/bounce/page_address fixes
per super block write_super needs an async flag
addres_space needs a VM pressure/flush callback
per file_op rw_kiovec
enhanced disk statistics
Fix routing by fwmark
put_user appears to be broken for i386 machines
Returned Peace Corps IT Volunteer
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.
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
I was really hoping that some work on getting APM working under SMP would go in before 2.4.0, but alas, it seems not to have made the "to be added" list. I really miss the "power off on shutdown" option - that made my life a little easier before I got a UPS. Oh well, I guess I could wait a little longer, as it's not a necessary feature. Now if I could only get drivers for that dang blasted Efficient Networks Speedstream 3060 ADSL NIC. :) Stoopid BellSouth...
XenoWolf The Original - Since 1993
If you are talking about just plain "Linux programming" (i.e. not the kernel) I suggest you do the following:
1) Buy "Beginning Linux Programming". The first edition was great, the second looks even better.
2) If you subscribe to Linux Journal, ask the editors to start a "Newbie Programmer" column. I recently sent them an offer to write such a column and having demand roll in would help a lot. 8^)
---
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
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)
Start by trying all the features you can marked (FIXED) or (FIXED ?). They require the simplest effort but are the most useful to someone who may or may not have the hardware on hand. Make an ISO partition greater than 4Gb and use it. Attempt some of the stuff he says 'isn't SMP freindly' on a SMP. Take copious mental notes of the results, and a bug report (or an 'It Works!) sent his way would be nice.
Welcome to the Linux Quality Assurance Team!
.sig: Now legally binding!
Does anybody know if 2.3.x (2.4) will support the Adaptec Raid adapters, specifically the AAA-13x series? I really want a linux driver badly for this card. I got it before I even found out Linux existed. Adaptec's driver support really sucks, so don't imagine I'll ever be seeing them release the driver. Hell, they don't even have a win2000 driver for it. Thanks for you help in advance!
Have you checked out SGI's patches for
NFSV3 against the 2.2.10 kernel?
Works fine for me as an NFS3 client.
oss.sgi.com/projects
Also included as part of SGI's modified version
of Redhat, sgilinux 1.1.
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 little out of date. The kernel I'm running on my latest test f/w disk is 2.3.35, and initrd is working fine on that. Admittedly they had a slight problem with earlier versions but its fixed as of days.
You can't win a fight.
The whole point of Open Source is that YOU don't need to be all that great. Take what you've done and go to l-k with a request for testers, coders, etc. They'll find/fix your errors and viola! we have a softmodem driver.
---
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
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.
Take a look at it here...
----
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. :)
Devfs has been available as a patch to the kernel for a long time now; if it's not in yet, I'm not sure why it would be expected to go in now...
If you're not part of the solution, you're part of the precipitate.
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
We need a logical volume manager! Heinz Mauelshagen has written one (read about it here, and it appears to be stable. This has got to be part of the Linux core before using it in a large environment is reasonable. Those of us coming from other Unix backgrounds have been gritting our teeth at the lack of both a mature JFS AND an LVM.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
That goes to suggest that the testing scheme needs to be highly distributed, so that it checks to see what hardware is there is on a particular box, and tests that hardware. And submits the results back to a central site that would collect the results of tests together.
If you're not part of the solution, you're part of the precipitate.
somebody moderate that post up, Linux Device Drivers was invaluable in walking me thru my first, for real, production device driver with no more knowledge than C and an idea of how memory mapping works.... the book kicks some serious booty.
Then again, so does that bucking bronco on the front... not to mention the operating system it's written about. It's pretty fscking cool when you can write your first driver on your everyday werk box, making liberal use of insmod and rmmod, and only really freak it out three or four times over the course of six weeks' work.
Good luck on the device driver....
(lucky bastard... wish I had time to hack some more of those...)
In the coming releases.. Instead of adding support for a whole lot of neat and new things. Perhaps making what we have better? Code audits fix ups. Just in my spare time of learning a little about the LInux Kernel ive seen a few little things here and there. It would be sort of nice to audit the code like the OpenBSD folks did. But that put the operating system a bit behind and made it not so much for the "bleeding edge" types which thrive on linux.
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.
moderators - how is this redundant when it's the first post?
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
futile and unlikely.
All of 2000 now refers to \Device\Harddisk0\Partition1. All of 2000 will name your hard drives according to what port and channel they're instralled on. Now why didn't we think of that? We did 30 years ago. Letter names will disappear soon. 2000 already has the mount syscall.
2000 Server comes with a (gasp) Mount point manager.
I'm sorry but I have no reason to switch back to Windows.
Is Linux missing some things? Sure. Are the betas of those portions kicking ass already? Most certainly.
The message on the other side of this sig is false.
> How good is Linux at (Remote Access) RAS,
...the list goes on (note, everthing i list is >free with windows)...
Telnet?
> Componentization (COM+),
GNOME and KDE both have good versions of this.
> Telephony (TAPI),
Dunno but I remmber seeing an app advertised on freshmeat thats been around since 96 to do this.
> Speech (SAPI),
There's something for it, can't remember what.
> 3D (DirectX),
DirectX sucks.
OpenGL works fine.
> DataAccess (ODBC),
Ummmm,
MySQL, Oracle
.....
> Accessibility (MSA)
Fairly good
> Transaction Servers (MTS),
No idea.
> Message Queuing (MSMQ),
Haven't a clue
> IIS,
Now you're just being silly.
I've forgotten what it's called...
Oh yeah apache
> ASP,
php
> ActiveX,
Com+ in a fancy name.
> PnP..etc
2.3 supports my pnp cards without any hassle.
In fact I've had more luck with pnp stuff
under linux, than under windows.
>
Free to obtain,
how much does it cost to have more than 10people using it at once?