Re: BUG FOUND: Re: Potentially serious problem with kernel-headers...
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?
-Steve
--
/* -- Stephen Carpenter <sjc@delphi.com> --- <sjc@debian.org>------------ */
E-mail "Bumper Stickers":
"A FREE America or a Drug-Free America: You can't have both!"
"honk if you Love Linux"
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: