Re: Upgrading to a test kernel

David Woodhouse (
Fri, 22 May 1998 13:20:03 +0200

-> Kernel modules modutils-2.1.55-4 modutils-2.1.85

modutils-2.1.85 is in Red Hat's contrib directory.

Binutils binutils-

I managed without. is also in the contrib directory though.

-> Linux C Library libc-5.3.12-25 5.4.44

Ignore it. You're using glibc.

-> Procinfo procinfo-0.11-1 13

Ignore it or upgrade from the contrib directory.

-> Mount mount-2.7f-1 2.7l

Ignore it, but there's also one available.

-> Net-tools net-tools-1.33-4 1.45

This works OK, but will give false statistics, reporting TX packets as errors.

-> Loadlin not installed 1.6a

Ignore it.

-> NFS not installed 0.4.21

That's the kernel NFS daemon. If you're not using it, ignore it.

-> Ncpfs ncpfs-2.0.11-3 2.2.0

If you're not using ncpfs, don't bother. ncpfs-2.2.0 will work with older 2.0
kernels, while ncpfs-2.1.1 only works with 2.1 kernels

-> Pcmcia-cs pcmcia-cs-2.9.12-4 3.0.1

If you're not using PCMCIA, ignore it.

-> PPP ppp-2.3.3-2 2.3.5

You need this one. Curiously enough, it's also in Red Hat's contrib directory.

> If I install the newer version, will it not allow my existing 2.0.34
> kernel to work properly?

In all cases, the new one should work with either kernel.

> Is there a way to have both kernels working on the system, without
> having to repartition the drive?

Yes. (Assuming you're using LILO)
Put entries for both of them in /etc/lilo.conf.


The one at the top is the default, and if I want to revert to the 2.0.32
version for some reason, then I can type "linux-stable" at the LILO prompt.

> Also, I've heard folks talking about gcc, pgcc and egcs. I'm assuming
> that these are all C compilers, but what's up with them?

gcc is the old version of the GNU C compiler that we all know and love,
and we've got so used to working round its bugs that we now think they're part
of the ANSI spec. Note the "-f no-strength-reduce" in the kernel Makefile,
which is specifically to avoid a GCC bug.

Long ago, people decided that they'd like it to be aware of the Pentium CPU,
and perhaps even perform some optimisation for it, and the pgcc project was
born. For more information, see

A later version of gcc is being worked on, gcc-2.8.x, which has a few new
features. I have no idea where this fits in to the picture.

Because gcc-2.8 was taking so long to come out, and because lots of neat
features were rejected, yet another project was born, the 'egcs' (pronounced
'eggs') compiler. See

The pgcc project has now converted, and is based on egcs instead of gcc. I'm
not entirely sure why they haven't merged completely, but I think it's because
some of the more hairy optimisations still won't be accepted into egcs yet.

> I thought gcc was the compiler that we currently use. Is there a
> movement underway to switch to a new standard C compiler for Linux?

Nope. Hopefully, all of them will be usable. Sometimes things break, and it's
either because the compiler's optimisations are buggered, or because the code
was wrong (or ambiguous) in the first place and gcc-2.7.2 just happened to get
it right be accident.

In the latter case, the code is fixed, and in the former, Linus quite rightly
refuses to work around it, and the compiler bug tends to get fixed quite
quickly. There were a few debates about this for a while, but it seems to have
settled down now, and once the blame has been attributed, the group
responsible for the offending code tends to sort it out quite happily.

The one recent exception to this was when it was in fact the _documentation_
which was wrong, so the kernel conformed to the spec, and the compiler worked
as it thought it should, but they didn't agree. That one took a bit longer to
work out, because it led to arguments over how the compiler _should_ behave,
but now it's done.

(Disclaimer: the above is from an outsider who just tries to keep his compiler
up to date, so it's not Gospel. You get the idea though.)

---- ---- ----
David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355
finger for PGP key.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to