Ok, I'm just uploading the new version of the kernel, v1.3.33, also known as "the buggiest kernel ever". I'd be very happy if people would test it out, but _especially_ happy if kernel driver authors would test out that their respective drivers still work at all..
(if the above made non-driver people nervous, then yes, you probably have reason to be.. Feel free to test it out, but don't be too surprised if it does something strange)
What happened is that I finally gave up on the old driver initialization scheme, which initialized the hardware at a very early stage in the kenrel bootup process. The old init routines were called when the memory manegement wasn't fully initialized yet, and the kernel wasn't even scheduling processes.
That old scheme (which was mostly used due to historical reasons) lead to no end of problems for drivers that needed to sleep during initialization, or drivers that wanted to be usable both as a module and as a boot-time driver (because when the driver was initialized as a module, the circumstances were completely different from being initialized at bootup..)
Anyway, the 1.3.33 kernel fixes all this. Lots of drivers got a lot cleaner by this (less #ifdef MODULE type stuff, and better memory management when the driver can depend on "kmalloc()" etc at init time). So 1.3.33 is perfect, right?
Well...
The problem is that I have only been able to test the drivers I actually use myself: at the current time that is the keyboard, a 3c509 ethernet card, the serial lines and ide harddisk/cdrom. They work fine for me. I won't guarantee that they work fine for you ;-)
The other drivers at least compile (I did test them that much, although I haven't tried to compile them as modules), but have had no testing. The SCSI drivers in particular had some "interesting" memory management code for the initialization phase, and while I've tried to make them work, I will make no guarantees at all. If they don't work, you can be happy in the knowledge that they are at least a lot cleaner now. Nonfunctional, but cleaner.
Oops. I didn't even compile the sound driver. That probably fails to even compile. Hannu?
Scott, Mark: I had to move the call to "ide_cdrom_setup()", because it looks like it was previously called before the size[] array was even correctly set up.. Could you check this out? Also, Mark, I changed the ide memory allocation stuff, and triton.c now gets a page with "__get_dma_page()" instead of the previous strangeness.
Essentially, the drivers are now initialized only once we have a fully working memory management, and they are called from task[1] which may actually sleep, so you don't have to do busy polling for init routines any more. Also, the init interface is generally more like a loadable module, so any driver which already works as a module should be reasonably easy to fix up (I've tried to do it myself, but testing is 90% of the work, so..)