[tulip] RH7.0 issues with tulip.c and problems the new web site does not for me

Donald Becker becker@scyld.com
Fri, 24 Nov 2000 13:30:17 -0500 (EST)


On Fri, 24 Nov 2000, Daniel Roesen wrote:

> On Fri, Nov 24, 2000 at 02:30:28AM -0500, james hill wrote:
> > Red Hat 7.0 has a flawed configuration with their default install.
> I can't see any Kernel headers / GCC related ones.

Oh, really?  Do you have blinders on?
There have been many newsgroup and list posts with the same problem.

If one person has a problem with a change you make, they might be an idiot.
If thousands of people have problem, you are the idiot.

> > It uses the header files from an unreleased 2.3.99 kernel, rather
> > than installing the header files from the kernel that is actually
> > running.
> 
> This is how it is supposed to be. The installed headers should be
> the ones against which the glibc is compiled. They are not
> supposed to reflect the running kernel at all.

Yes, I know what the _claim_ is.  But the change doesn't make sense.

The header file set in Red Hat 7.0 is not merely missing details.
It is specifically wrong for the running system.
This is broken.

The header files set was from some random development kernel snapshot.
The pre-2.4 kernel has already changed dramatically.
So now the "kernel" header files don't match any kernel.

If this was a designed change, the kernel header files from the major stable
kernel generations would have been examined and the relevant definitions
extracted.  These would have specified the kernel to library interface, and
any kernel version differences would have been noted and resolved.

A less good approach would have been to start from a stable 2.2 kernel and
remove everything inside #ifdef KERNEL

Instead the sleaziest of hack jobs was done.  The evidence is right here:
strictly internal kernel structures from an unstable kernel are now
considered part of glibc.  This definition there were correct only for about
a week, and no one today is running that kernel version.  (People that run
2.3.99.N are not intending to run their machines a year between reboots.
They switch to 2.3.99.N+1 about five minutes after it shows up.)

There was certainly a better split between kernel and glibc header files.
But it doesn't appear that anyone spent even a few minutes considering how
best to do it before leaping to action and causing man-years of problems.

> > A second problem is that 7.0 provides an experimental version of gcc
> > that was not intended for public release.
> 
> Where's the problem with it? [please don't answer. that question
> was rhetorical]

Then why make the comment?
This has been widely covered: Red Hat made a mistake.

The specific problem is that gcc was half-way to changing the function
calling conventions and structure layout.  There is now yet another binary
interface standard.  It was introduced by the largest Linux distribution, so
it will be around until the end of time.  Doesn't anyone remember what
nearly killed UNIX?

> > The Makefile in the tar file and RPM automatically include this
> > compile flag, however they cannot automatically use 'kgcc'. 
> 
> Current Linux kernel sources do.

I'm providing driver updates that work with kernel versions back to 1.2.0.

People running the latest Linux development kernels see no problem with
instruction that read "update programs foo, bar, and baz.  You must be
running gcc X.Y.Z and rename it to kxy-gcc".  Changes that are seem
reasonable in a rapidly changing development environment are not acceptable
when trying to make controlled, limited updates to production systems.

> > To repeat: this is a flaw that was introduced with Red Hat 7.0.
> > It is a Red Hat configuration problem, not a driver 
> 
> Prove your accusations or be quiet. You obviously don't know what
> you're talking about.

Hmmm, before asking me to be quiet you should look at the list return
address.  And I likely have a bit more experience than you.  I'm certainly
the person that is getting the blame and has to deal with the pain created
by this mistake.


Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
Annapolis MD 21403			410-990-9993