Re: Pioneer DVR-106D issues
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
Reply to: