lkml.org 
[lkml]   [2000]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Kernel 2.2.17 with RedHat 7 Problem !
On Mon, Oct 23, 2000 at 01:00:14AM +0200, J . A . Magallon wrote:
> On Mon, 23 Oct 2000 00:36:14 Gregory Maxwell wrote:
> >
> > > I am now compiling my 2.2.18-pre kernels with gcc-2.95 and work fine. It is
> > > 2.96 what is broken.
> >
> > It compiles. Does it really work fine for all tasks and all people? Who
> > knows. It is know that your described configuration is not very well tested.
> >
> > If 2.96 is broken, I'd appreciate it if you would describe the breakage.
>
> With the kernel, it refuses to compile somehthing (checksum.S) related with
> varargs in macros that is perefectly legal reading the info files for gcc.

The file is compiled with -traditional. The ellipses (for optionality) are a
GNU extension. The kernel contains the bug. Not gcc.

The kernel gurus agree that the kernel is broken and not GCC.
for example:
http://www.cs.helsinki.fi/linux/linux-kernel/2000-39/0495.html

> > RedHat (and others) doesn't just call 'their' 2.2.16 2.2.16. RedHat 7 ships
> > with a 2.2.16-22 which is the richest description that the current framework
> > allows. They also ship a source package which contains each patch separate
> > from the source.
>
> The '22' there is the package version, not related to the gcc or kernel
> version. When RH (or Mandrake) package a thing in an rpm, is thing-2.3.4-1.rpm.
> If they discover the left a pair of icons at home, the new package is
> thing-2.3.4-2.rpm. If they misplaced an script, new one is thing-2.3.4-3.rpm.
> But thing is still 2.3.4. So you could have kernel-2.2.18pre7-1.rpm.
> If they discover a patch was badly applied, public kernel-2.2.18pre7-2.rpm.
> If they apply NEW patches, from pre 8, it is now kernel-2.2.18pre8-1.rpm.

Applying patches, adding scripts, etc sure sounds like a new version to me.

And the kernel that ships with RedHat 7 is 2.2.16 + patches and is
called (by them) 2.2.16-22 (which is what uname reports too). This kernel
has numerous advantages over 2.2.17.


> >
> > The unfortunate consequence of the kernel versioning is most users can't
> > understand that 2.2.16-22 > 2.2.17 in terms of usability for most users.
> >
>
> And should not be that way, because 17 usually includes all the patches to
> 16 that mutate it in -22, and even more.

It doesn't. 17 doesn't included 1/4 of what is in RedHat's 2.2.16-22 and
2.2.16-22 doesn't include everything in 2.2.17 (it's called testing and
avoiding shipping software they haven't tested).

RedHat has no control over what goes into the mainline 2.2.n.

You are completely nuts if you think that distributions should wait
for a feature to appear in the mainline before including it in their
distribution.

Doing so would certainly have a negative effect on the development of the
mainline kernel due to pressure to include features that are not ready for
the mainline.

Distributors have different goals from the mainline kernel developers, and
thus they ship different kernels.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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