JS> The recent Linux kernels are full of IDE related bugs :-( Here I can mostly agree - several IDE drivers have bugs, mostly DMA related (sine most of IDE is DMA nowadays). In addition people report their IRQ routing bugs as IDE when IDE IRQ doesn't happen but this is rather an ACPI BIOS / Intel ACPI code / Linux chipset-specific IRQ routing problem. Disabling ACPI usually fixes the IRQ problems.
Not that other operating systems don't have IDE bugs - I have struggled with IDE problems that looked like driver bugs in Solaris too. Not that would prove anything, we know there is no bugfree software. JS> A big problem is that Linux kernels are not compiles with a decent set JS> of GCC warning messages enable (maybe because they include so ugly code). Quite possible. The current Linux kernel uses the following warning and code-generation options on my x86 system: -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -mpreferred-stack-boundary=2 -march=pentium3 -fomit-frame-pointer What options do you suggest that don't give false positives? You can't use warnings with false positives in such a big piece of code, people would just start ignoring meaningful warnings too whan they get used to seeing many warnings. But quite possibly there are some gcc warning options that would be useful. What options would you suggest adding? JS> Some peole completely did rework IDE internals (mainly in the DMA area) JS> and did change the number of parameters to functions. While a direct JS> function call with a parameter missmatch would result in a compilation JS> abort (with GCC at least ends up with a big warning), this cannot directly JS> be noticed as the functions get called via a function pointer. As long JS> as you don't enable compiler warnings for bad pointer assignements, you will JS> never see a warning for this kind of broken source... Are you sure you know what yo are talking here? Have you actually looked at the code? I did have a look at current Linux kernel IDE code and like other parts of the kernel, IDE code and drivers use strongly typed function pointers everywhere. Vast mayority of function parameters are also strongly typed for any non-atomic types. The only functions I found that have void* arguments that are not IO addresses are the following: extern void ata_input_data(ide_drive_t *, void *, u32); extern void ata_output_data(ide_drive_t *, void *, u32); extern void atapi_input_bytes(ide_drive_t *, void *, u32); extern void atapi_output_bytes(ide_drive_t *, void *, u32); extern void taskfile_input_data(ide_drive_t *, void *, u32); extern void taskfile_output_data(ide_drive_t *, void *, u32); The void* here is buffer address that uses different types and sizes of buffers for different code paths so it is hard to come up with a universal buffer type that would actually catch misuses. So I would say Linux IDE code uses strongly typed function pointers. Period. In addition, it mostly uses strongly typed arguments too. -- Meelis Roos