Messages in this thread | | | From | Monty <> | Subject | Re: Kernel interface changes (was Re: cdrecord problems on recent Linux versions) | Date | Wed, 03 Feb 1999 19:31:50 EST |
| |
>> The worry is that kernel developers are not paying much attention to >> these sorts of 'bugs'; they don't consider these changes to be a >> problem. I'm glad that my main immediate concern was possibly >> unfounded, but the content of the flame still stands. > >This addressed to the kernel developers who dropped the attempt to merge >message queue improvements to 2.2 because it was causing compatibility >complexities ?
Yes, I am. I'm not talking about avoiding only major changes. I'm talking about consistency in the way exposed, published kernel interfaces are treated-- big and small. As you state above, you did the right thing, and I'm glad. But the joy is derived from "not being shot in the foot" more than it is "a desire to congratulate the group for doing the only reasonable thing".
>I think everyone tries to avoid stuff like that. Internal to kernel stability >is very hard to do. External API's should _never_ need to become incompatible, >at worst they will bite incorrectly coded programs tht perhaps assume a >reserved field will end up zero.
"Do or do not. There is no try."
Sorry, couldn't resist ;-)
More details about my example...
Cdparanoia uses the HDIO_GET_IDENTITY ioctl. It is not the only package that uses it. Cdrecord, cdda2wav and pcmcia services (!) all got nailed by this change. From 2.0.33 to 2.0.34 (sorry, I misreported this earlier as 2.0.34->35. 2.0.33->34 is correct), the size of the argument struct passed to the ioctl grew... And the extra bytes were padding! They held nothing. They added no functionality.
How were these pagakes 'incorrectly coded' such that they could have expected this change?
>> 5.3 was riddled with bounds bugs that didn't get fixed until 5.4. > >Actually the RH tree had all the security holes fixed. I never had good >experience with 5.3+linxuthreads and since this code ticks over nicely in >glibc Im inclined to assume 5.3 had bugs there.
I'm not talking about security holes. I'm talking about 5.3.n's strcpy() copying <n> bytes too far in the pentium optimized assembly and segfaulting. I'm talking about memcmp making alignment errors, etc. These are not minor security holes; these are 'all programs relying on ANSI string handling go *boom* randomly'.
And, once the bugs were found, they were fixed. That also isn't my problem. My problem is that in the meantime, in a subminor release, libc was made incompatable with all previous version in a fundamental way. *No* program dynamically linked against a previous version would function any longer because the lookup tables in the compile-time headers changed. This is not a minor bug! Nor has this kind of bug been a rarity.
*That* is my problem.
Monty
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |