lkml.org 
[lkml]   [1999]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Kernel interface changes (was Re: cdrecord problems on recent Linux versions)
Date

>> 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/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.046 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site