>From: Meelis Roos <[EMAIL PROTECTED]> >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. ---> Solaris x86: "eeprom acpi-user-options=0x02" >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. It is interesting to me that I only find few real bugs in Solaris 86. It is on most cases a need to just set up the BIOS "correctly". However, once you did this on Solaris x86, the problems usually did go away completely - on Linux other problems start to become obvious. >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 In the Schily makefile system (Developer set up) these warning options are used: CWOPTS= -Wall -Wtraditional \ -Wshadow -Wmissing-prototypes -Wstrict-prototypes -Wtraditional more and more created problems with GCC-3.x >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? May be the problem is that there just too many false warnings so people did oversee the real bugs. >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 _I_ am definitely sure, I did try to fix DMA for a driver 6 months ago.... >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); _You_ are looking at the wrong places :-( The important things are called via function pointers that are in a structure... This is why you don"t get a compiler warning for bad function usage but for a "illegal pointer combination" only. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) If you don't have iso-8859-1 [EMAIL PROTECTED] (work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily