Re: BUG FOUND: Re: Potentially serious problem with kernel-headers...
On Thu, 16 Jul 1998, Stephen J. Carpenter wrote:
> On Thu, Jul 16, 1998 at 11:12:34AM -0400, Dale Scheetz wrote:
> > On Thu, 16 Jul 1998, Brian White wrote:
> >
> > > We are delivering a 2.0.34 kernel. We're going to have to bite the bullet
> > > with this one and fix it in Slink. I'd like to know the results of the
> > > source grep for HDIO_GET_IDENTITY, though. I can't see that call being
> > > very common.
> > >
> > >
> > > > Brian, what do you think about this. Are we delivering 2.0.34 and 2.0.35
> > > > kernels? If we are, the current situation will result in several broken
> > > > packages. If we aren't it can wait til slink. It looks like we can loose
> > > > either way. The current situation has "known" problems, while the repaired
> > > > situation would have "unknown" ones.
> > >
> > > Plus we'd there would be a number of package recompiles, then possibly
> > > recompiles of those packages that depend on them, plus the other archs
> > > would need to recompile... That could take weeks on its own, not even
> > > counting the time needed to fix any bugs that crop in.
> > >
> > Both H.J. and Ulrich suggest that there is no problem moving to the 2.0.34
> > headers as they both build their glibc against 2.1.x kernel headers with
> > no problems.
> >
> > I agree, however, that now is not the time to "fix" this. Slink will be a
> > natural place to switch kernel headers. The few packages that are broken
> > in this fashion only need to build against 2.0.34 headers to deliver
> > functional programs.
>
> I agree with not going to 2.0.34 headers but...
> if I understand the problem right... the structure got bigger...
> so the reason it works one way only is that building against the
> 2.0.34 headers on a 2.0.33 program allocates a little bit (probbaly on
> the order of a few bytes...but thats just a guess) more memory for
> the sturcture than is needed for that kernel...soo...
>
> why not just patch the current libc6 kernel headers with this
> new structure and add a note to the headers...
> that will solve this 1 problem without introducing new ones
> (unless you think that in itself could add new bugs? but I don't
> see how that could add a bug)
>
> at least that would allow people who move to the newer kernel to re-compile
> these programs
>
> any thoughts?
As all the packages that currently exhibit this problem have or are
already being rebuilt against the proper headers, I see no reason to
introduce a hack fix into glibc this close to release.
I intend to make one more release of glibc before hamm goes out the door,
which fixes a security hole in the LD_PRELOAD patch, and brings the source
up-to-date with the CVS archives.
After the release, it is my intention to move the -dev package to kernel
headers from one of the stable 2.1.x kernels, as the rest of the glibc
developers are already doing. This will go into slink until there is ample
evidence that it will not break hamm, at which point it may propogate into
the stable release.
Luck,
Dwarf
--
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: