OK, I'll look with the assumtion that nothing should have changed in mind.
As for SG problems, I can fill several pages with them, but that's a
different (well known) subject.
>> for no good reason. You might have *thought* that just bumping up the
>> size of the argument struct to a single ioctl from 2.0.34->2.0.35 was
>
>That would count as a bug. I can't find the report in my 2.0.34pre archive
I have the whole email exchange archived if necessary (you commented
on it at the time). It's water under the bridge now.
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.
>> and its lookup tables for example). A binary built against 5.3
>> segfaults when run with 5.4 and vice versa. So, everything is
>> statically linked. Thank you Foresight.
>
>There are reasons people like Red Hat didnt go to 5.4 8)
5.3 was riddled with bounds bugs that didn't get fixed until 5.4.
You'd segfault all the time sticking with 5.3... but you'd have to
rebuild everything to use 5.4. Upgrading mindlessly (it was, after all
a subminor release change that introduced the incompatability) would
make matters even worse. There was no reason to make those changes to
a minor release of libc. Again, the ideas behind the flame stand.
>The kernel SG api hasnt afaik changed. All my old binaries run, the glibc
>binaries I have run fine too (SANE for example).
This change would cause heisenbugs, not certain failure. The
2.0.34->2.0.35 ioctl struct size change I mention above only ever
produced segfaults for two of my users. Everyone else managed to keep
running, just happening not to page fault in the wrong place. It was
still a bug.
I'll report on the results of my hunting.
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/