(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..)
Linus