Re: 2.0.33 headers break progs in 2.0.34 kernels

[hjl@lucon.org (H.J. Lu)]

> 
> I'm in a dilema of sorts for several reasons. Debian is due to release in
> about a week, and kernel headers have broken some things.
> 
> Here is the report:
> 
> > The hd_driveid struct in linux/include/linux/hdreg.h got bigger.
> > Calling the HDIO_GET_IDENTITY ioctl() (a published interface to the
> > ide subsystem) will cause a 2.0.33 or before application to trash its
> > data segment/stack under 2.0.34.  If the application is built against
> > 2.0.34 (and more importantly the 2.0.34 headers), the ioctl is safe
> > under 2.0.33.
> 
> The size of a data structure seems to have grown, resulting in a program
> compiled with 2.0.33 headers to crash when run on a 2.0.34 kernel, if it
> uses this ioctl call.
> 
> Since the program compiled against a 2.0.34 kernel header will work on a
> 2.0.33 kernel, compiling those packages against that header fixes the
> problem.
> 
> The question for me is, how likely are other things going to break if I
> move the glibc package up to the 2.0.34/35 kernel headers? This close to
> the release, I am reticent to make such a "drastic" change, specially when
> the known programs can be delivered properly by compiling them special.
> 
> I guess I am mostly fishing for a better approach. Anyone have a
> suggestion?

That is a known issue. I am running Linux 2.0.35. But I am using the
header files from the very recent Linux kernel, 2.1.106. I think it
is safe to use them to compile glibc.


H.J.