support of older compilers

support of older compilers

[Timothy Miller]

I'm just curious about why there seems to be so much work going into 
supporting a wide range of GCC versions.  If people are willing to 
download and compile a new kernel (and migrating from 2.4 to 2.6 is 
non-trivial for some systems, like RH9), why aren't they willing to also 
download and build a new compiler?

Re: support of older compilers

[Christoph Hellwig]

On Wed, Nov 03, 2004 at 04:02:49PM -0500, Timothy Miller wrote:
> I'm just curious about why there seems to be so much work going into 
> supporting a wide range of GCC versions.  If people are willing to 
> download and compile a new kernel (and migrating from 2.4 to 2.6 is 
> non-trivial for some systems, like RH9), why aren't they willing to also 
> download and build a new compiler?

Because the new compilers are a lot slower.

Re: support of older compilers

[Chris Wedgwood]

On Wed, Nov 03, 2004 at 09:13:53PM +0000, Christoph Hellwig wrote:

> Because the new compilers are a lot slower.

next you'll be claiming newer kernels are much larger than older
kernels (for similiar features)

Re: support of older compilers

[Adam Heath]

On Wed, 3 Nov 2004, Christoph Hellwig wrote:

> On Wed, Nov 03, 2004 at 04:02:49PM -0500, Timothy Miller wrote:
> > I'm just curious about why there seems to be so much work going into
> > supporting a wide range of GCC versions.  If people are willing to
> > download and compile a new kernel (and migrating from 2.4 to 2.6 is
> > non-trivial for some systems, like RH9), why aren't they willing to also
> > download and build a new compiler?
>
> Because the new compilers are a lot slower.

You can't be serious that this is a problem.

Re: support of older compilers

[Chris Wedgwood]

On Wed, Nov 03, 2004 at 05:06:56PM -0600, Adam Heath wrote:

> You can't be serious that this is a problem.

try it, say gcc 2.95 vs gcc 4.0 ... i think last i checked the older
gcc was over twice as fast

Re: support of older compilers

[Adam Heath]

On Wed, 3 Nov 2004, Chris Wedgwood wrote:

> On Wed, Nov 03, 2004 at 05:06:56PM -0600, Adam Heath wrote:
>
> > You can't be serious that this is a problem.
>
> try it, say gcc 2.95 vs gcc 4.0 ... i think last i checked the older
> gcc was over twice as fast

I didn't deny the speed difference of older and newer compilers.

But why is this an issue when compiling a kernel?  How often do you compile
your kernel?

Re: support of older compilers

[Chris Friesen]

Adam Heath wrote:

> I didn't deny the speed difference of older and newer compilers.
> 
> But why is this an issue when compiling a kernel?  How often do you compile
> your kernel?

You're posting to the kernel development list--many people here recompile dozens 
of times a day.

Chris

Re: support of older compilers

[Adam Heath]

On Thu, 4 Nov 2004, Chris Friesen wrote:

> Adam Heath wrote:
>
> > I didn't deny the speed difference of older and newer compilers.
> >
> > But why is this an issue when compiling a kernel?  How often do you compile
> > your kernel?
>
> You're posting to the kernel development list--many people here recompile dozens
> of times a day.

So find the fastest computer you have, and use that.  There is no need to
compile a kernel on the machine it will be run on.

Re: support of older compilers

[Willy Tarreau]

On Thu, Nov 04, 2004 at 12:17:01PM -0600, Adam Heath wrote:
> > You're posting to the kernel development list--many people here recompile dozens
> > of times a day.
> 
> So find the fastest computer you have, and use that.  There is no need to
> compile a kernel on the machine it will be run on.

Uhh ?

What are you smoking ? We all have the fastest computers we can buy, and
since a kernel still takes a few minutes to compile on those computers,
we try to use the fastest compilers to save *HOURS* at the end of the day.
Nobody ever claimed that we all spend our time compiling on the target
system. I wonder if thas would be possible on a 16 MB/200 MHz MIPS ;-)

That's it.

Willy

Re: support of older compilers

[Geert Uytterhoeven]

On Fri, 5 Nov 2004, Willy Tarreau wrote:
> On Thu, Nov 04, 2004 at 12:17:01PM -0600, Adam Heath wrote:
> > > You're posting to the kernel development list--many people here recompile dozens
> > > of times a day.
> > 
> > So find the fastest computer you have, and use that.  There is no need to
> > compile a kernel on the machine it will be run on.
> 
> Uhh ?
> 
> What are you smoking ? We all have the fastest computers we can buy, and
> since a kernel still takes a few minutes to compile on those computers,
> we try to use the fastest compilers to save *HOURS* at the end of the day.
> Nobody ever claimed that we all spend our time compiling on the target
> system. I wonder if thas would be possible on a 16 MB/200 MHz MIPS ;-)

Why not? 16 MB and 200 MHz used to be plenty!

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: support of older compilers

[Willy Tarreau]

On Fri, Nov 05, 2004 at 09:28:58PM +0100, Geert Uytterhoeven wrote:
> > Nobody ever claimed that we all spend our time compiling on the target
> > system. I wonder if thas would be possible on a 16 MB/200 MHz MIPS ;-)
> 
> Why not? 16 MB and 200 MHz used to be plenty!

Yes, sorry, I forgot to mention that instead of disk, I only have 8 MB
flash :-) Of course, I could do it over NFS, yes...

Cheers,
Willy

Re: support of older compilers

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 457 bytes --]

On Thu, 04 Nov 2004 10:50:38 CST, Adam Heath said:

> I didn't deny the speed difference of older and newer compilers.
> 
> But why is this an issue when compiling a kernel?  How often do you compile
> your kernel?

If you're working on older hardware (note the number of people on this
list still using 500mz Pentium3 and similar), and a kernel developer, the
difference between 2 hours to build a kernel and 4 hours to build a
kernel matters quite a bit.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: support of older compilers

[Adam Heath]

On Thu, 4 Nov 2004,  wrote:

> On Thu, 04 Nov 2004 10:50:38 CST, Adam Heath said:
>
> > I didn't deny the speed difference of older and newer compilers.
> >
> > But why is this an issue when compiling a kernel?  How often do you compile
> > your kernel?
>
> If you're working on older hardware (note the number of people on this
> list still using 500mz Pentium3 and similar), and a kernel developer, the
> difference between 2 hours to build a kernel and 4 hours to build a
> kernel matters quite a bit.

Use faster hardware to compile a kernel.  Cross-compiling is easy for kernels.

Plus, at least on i386/debian, kernel-package makes it easy.

Again, your argument doesn't hold water.

Re: support of older compilers

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 616 bytes --]

On Thu, 04 Nov 2004 12:15:47 CST, Adam Heath said:

> Use faster hardware to compile a kernel.  Cross-compiling is easy for kernels
.

Hmm.. Send some faster hardware to Zwane then - I seem to recall
that his *faster* hardware was a 3-CPU 400mz box.

And then feel free to send faster hardware to everybody else on this
list who's not lucky enough to work for a company that will buy them
the latest-and-greatest.  For a lot of us, even a $700 consumer-class
machine is a major investment, and has to be balanced against things
like mortgages and food and keeping the car running so you can get to
your day job.....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: support of older compilers

[Adam Heath]

On Thu, 4 Nov 2004,  wrote:

> On Thu, 04 Nov 2004 12:15:47 CST, Adam Heath said:
>
> > Use faster hardware to compile a kernel.  Cross-compiling is easy for kernels
> .
>
> Hmm.. Send some faster hardware to Zwane then - I seem to recall
> that his *faster* hardware was a 3-CPU 400mz box.

my home box is dual celeron 333.  If that machine can't keep up, then the make
system itself is buggy(and yes, I've written a complex automake-like
system(not released)).

Re: support of older compilers

[Ian Romanick]

Adam Heath wrote:
> On Thu, 4 Nov 2004,  wrote:
>>On Thu, 04 Nov 2004 10:50:38 CST, Adam Heath said:
>>
>>>I didn't deny the speed difference of older and newer compilers.
>>>
>>>But why is this an issue when compiling a kernel?  How often do you compile
>>>your kernel?
>>
>>If you're working on older hardware (note the number of people on this
>>list still using 500mz Pentium3 and similar), and a kernel developer, the
>>difference between 2 hours to build a kernel and 4 hours to build a
>>kernel matters quite a bit.
> 
> Use faster hardware to compile a kernel.  Cross-compiling is easy for kernels.
> 
> Plus, at least on i386/debian, kernel-package makes it easy.

And if that 500MHz Pentium3 *IS* they fastest hardware they have? 
Should they just go carjack someone to fund a new system to make you 
happy? ;)  Not everyone has a corporation like IBM or Redhat to fund 
their hardware needs.  A lot of people that make real, valuable 
contributions to lk are on a shoestring budget.

Re: support of older compilers

[Christoph Hellwig]

On Thu, Nov 04, 2004 at 12:15:47PM -0600, Adam Heath wrote:
> Use faster hardware to compile a kernel.  Cross-compiling is easy for kernels.

I think I have pretty fast hardware (e.g. dual g5 18.GHZ and P4 4.2 GHz),
and for me a kernel compile still takes far too long.

But if you want to buy me a 512p Altix and the electricity bill so I can
use gcc 3.3 all power  to you!

Re: support of older compilers

[Giuseppe Bilotta]

Christoph Hellwig wrote:
> On Thu, Nov 04, 2004 at 12:15:47PM -0600, Adam Heath wrote:
> > Use faster hardware to compile a kernel.  Cross-compiling is easy for kernels.
> 
> I think I have pretty fast hardware (e.g. dual g5 18.GHZ and P4 4.2 GHz),
> and for me a kernel compile still takes far too long.

Even on the 18 GHz system? :)

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)

Re: support of older compilers

[Willy Tarreau]

On Thu, Nov 04, 2004 at 07:48:24PM +0000, Christoph Hellwig wrote:
> But if you want to buy me a 512p Altix and the electricity bill so I can
> use gcc 3.3 all power  to you!

By the time it would be assembled, the 2048p they announced this week will
be available. Wait a few months Christoph ;-)

Willy

Re: support of older compilers

[Ian Hastie]

On Thursday 04 Nov 2004 17:04, Valdis.Kletnieks@vt.edu wrote:
> On Thu, 04 Nov 2004 10:50:38 CST, Adam Heath said:
> > I didn't deny the speed difference of older and newer compilers.
> >
> > But why is this an issue when compiling a kernel?  How often do you
> > compile your kernel?
>
> If you're working on older hardware (note the number of people on this
> list still using 500mz Pentium3 and similar), and a kernel developer, the
> difference between 2 hours to build a kernel and 4 hours to build a
> kernel matters quite a bit.

How often is it necessary to do a full rebuild of the kernel?  If the 
dependencies in the make system work properly then only the amended parts 
should be recompiled.  That'd be a much bigger time saving than just using an 
older compiler.

-- 
Ian.

EOM

Re: support of older compilers

[Ioan Ionita]

Nobody mentioned that fact that newer versions of gcc, albeit slower
at compiling, do tend to generate binaries that have faster execution

On Thu, 4 Nov 2004 19:36:26 +0000, Ian Hastie <ianh@iahastie.clara.net> wrote:
> On Thursday 04 Nov 2004 17:04, Valdis.Kletnieks@vt.edu wrote:
> 
> 
> > On Thu, 04 Nov 2004 10:50:38 CST, Adam Heath said:
> > > I didn't deny the speed difference of older and newer compilers.
> > >
> > > But why is this an issue when compiling a kernel?  How often do you
> > > compile your kernel?
> >
> > If you're working on older hardware (note the number of people on this
> > list still using 500mz Pentium3 and similar), and a kernel developer, the
> > difference between 2 hours to build a kernel and 4 hours to build a
> > kernel matters quite a bit.
> 
> How often is it necessary to do a full rebuild of the kernel?  If the
> dependencies in the make system work properly then only the amended parts
> should be recompiled.  That'd be a much bigger time saving than just using an
> older compiler.
> 
> --
> Ian.
> 
> EOM
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: support of older compilers

[Adrian Bunk]

On Thu, Nov 04, 2004 at 07:36:26PM +0000, Ian Hastie wrote:
> On Thursday 04 Nov 2004 17:04, Valdis.Kletnieks@vt.edu wrote:
> > On Thu, 04 Nov 2004 10:50:38 CST, Adam Heath said:
> > > I didn't deny the speed difference of older and newer compilers.
> > >
> > > But why is this an issue when compiling a kernel?  How often do you
> > > compile your kernel?
> >
> > If you're working on older hardware (note the number of people on this
> > list still using 500mz Pentium3 and similar), and a kernel developer, the
> > difference between 2 hours to build a kernel and 4 hours to build a
> > kernel matters quite a bit.
> 
> How often is it necessary to do a full rebuild of the kernel?  If the 
> dependencies in the make system work properly then only the amended parts 
> should be recompiled.  That'd be a much bigger time saving than just using an 
> older compiler.

As soon as you touch include files, a full recompile occurs pretty 
often because there are some include files pretty every other file 
depends on (and has to depend on).

Well, although I'm doing full kernel compiles sometimes several times a 
day I'm not that much addicted to compiler speed but I do understand 
others are.

> Ian.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: support of older compilers

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 510 bytes --]

On Thu, 04 Nov 2004 19:36:26 GMT, Ian Hastie said:

> How often is it necessary to do a full rebuild of the kernel?  If the 
> dependencies in the make system work properly then only the amended parts 
> should be recompiled.  That'd be a much bigger time saving than just using an 
> older compiler.

Touch the wrong .h file, and 95% of the world still gets rebuilt. Similarly,
change the wrong CONFIG_ variable and thus the size/layout of a critical
structure, and watch 95% of the world still get rebuilt.


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: support of older compilers

[Linus Torvalds]

On Thu, 4 Nov 2004, Adam Heath wrote:
>
> On Wed, 3 Nov 2004, Chris Wedgwood wrote:
> 
> > On Wed, Nov 03, 2004 at 05:06:56PM -0600, Adam Heath wrote:
> >
> > > You can't be serious that this is a problem.
> >
> > try it, say gcc 2.95 vs gcc 4.0 ... i think last i checked the older
> > gcc was over twice as fast
> 
> I didn't deny the speed difference of older and newer compilers.
> 
> But why is this an issue when compiling a kernel?  How often do you compile
> your kernel?

First off, for some people that is literally where _most_ of the CPU 
cycles go.

Second, it's not just that the compilers are slower. Historically, new gcc 
versions are:
 - slower
 - generate worse code
 - buggier

For a _long_ time, the only reason to upgrade gcc was literally C++
support: basic C support was getting _worse_ with new compilers in pretty
much every regard.

Things seem to have improved a bit lately. The gcc-3.x series was 
basically not worth it for plain C until 3.3 or so.

		Linus

Re: support of older compilers

[Adam Heath]

On Thu, 4 Nov 2004, Linus Torvalds wrote:

> > I didn't deny the speed difference of older and newer compilers.
> >
> > But why is this an issue when compiling a kernel?  How often do you compile
> > your kernel?
>
> First off, for some people that is literally where _most_ of the CPU
> cycles go.

So find a fast machine.  As I have already said, you don't need to compile a
kernel for a slow machine/arch *on* a slow machine/arch.

> Second, it's not just that the compilers are slower. Historically, new gcc
> versions are:
>  - slower

Again, that's a straw man.

>  - generate worse code
>  - buggier

I don't doubt these are issues.  That's not what I am discussing.

Re: support of older compilers

[Linus Torvalds]

On Thu, 4 Nov 2004, Adam Heath wrote:
> >
> > First off, for some people that is literally where _most_ of the CPU
> > cycles go.
> 
> So find a fast machine.  As I have already said, you don't need to compile a
> kernel for a slow machine/arch *on* a slow machine/arch.

I _have_ a fast machine. Others don't. And quite frankly, even I tend to 
prioritize things like "nice and quiet" over absolute speed.

> I don't doubt these are issues.  That's not what I am discussing.

Sure it is. You're complaining that developers use old versions of gcc. 
They do so for a reason. Old versions of gcc are sometimes better. They 
are better in many ways.

Your "use new versions of gcc even if it is slower" argument doesn't make 
any _sense_. If the new versions aren't any better, why would you want to 
use them?

		Linus

Re: support of older compilers

[Adam Heath]

On Thu, 4 Nov 2004, Linus Torvalds wrote:

>
>
> On Thu, 4 Nov 2004, Adam Heath wrote:
> > >
> > > First off, for some people that is literally where _most_ of the CPU
> > > cycles go.
> >
> > So find a fast machine.  As I have already said, you don't need to compile a
> > kernel for a slow machine/arch *on* a slow machine/arch.
>
> I _have_ a fast machine. Others don't. And quite frankly, even I tend to
> prioritize things like "nice and quiet" over absolute speed.
>
> > I don't doubt these are issues.  That's not what I am discussing.
>
> Sure it is. You're complaining that developers use old versions of gcc.
> They do so for a reason. Old versions of gcc are sometimes better. They
> are better in many ways.

Using an old version of gcc because it is faster at compiling is a
non-argument.  If people don't bother using newer compilers, complaining
about their inefficiencies, then the issues will never be resolved.

I have no problem with older gccs if they produce more correct code.

> Your "use new versions of gcc even if it is slower" argument doesn't make
> any _sense_. If the new versions aren't any better, why would you want to
> use them?

That's not my argument.  Never has been.  I am against people who say not to
use newer gccs only on the grounds that they are slower.

If they produce bad code, then that's a valid reason.
If they produce larger code, that is a valid reason.

But slowness doesn't mean wrong, just by being slow.

ps: it seldom makes sense to use a single metric as a measure of the quality
    of some specific item in some specific situation.

Re: support of older compilers

[Linus Torvalds]

On Thu, 4 Nov 2004, Adam Heath wrote:
> 
> But slowness doesn't mean wrong, just by being slow.

No.

"Right" and "wrong" have _nothing_ to do with anything.

he only thing that matters is "what is the best tool". And yes, 
performance _is_ an issue in selecting the best tool. It's not the only 
one, but it's a major one.

You said so yourself when you claimed people should just buy faster 
hardware. Again, the machine you use is just another tool. Why should you 
buy a faster machine if performance doesn't matter?

I don't understand why you first dismiss performance, and then go on to
ignore all the _other_ issues I told you about too.

And your argument about "things will get fixed if you use the newer
version" is also not actually true. First off, if it ain't broke in the 
older version, then things _literally_ will get fixed by not upgrading in 
the first place.

And telling a developer "I'm not using your new version because it sucks
compared to the old one" is actually a perfectly valid thing to do, and is 
likely to be _more_ motivational for the developer to get it fixed than 
having users that just follow the newest version like stupid sheep.

There are people out there using Linux-2.0. There are probably people even
using linux-1.2. And hey, that's OK. For older machines it may really be
the right choice, especially if they are still doing the same thing they
did several years ago. The notion that you somehow "have to" upgrade to
the newest version of software is BOGUS.

		Linus

Re: support of older compilers

[Andries Brouwer]

[Ob l-k]

I have not yet investigated, but my (vanilla) 2.6.9
has a mouse problem that my vanilla 2.6.8.1 does not have:
it starts selecting text as soon as I touch it for the first
time, as if the initialization created a fake mouse-down event.


[old stuff]

> There are probably people even using linux-1.2.

# uname -a
Linux knuth 1.2.11 #27 Sun Jul 30 03:39:01 MET DST 1995 i486

(486 DX/2, 66MHz, 8 MB)

-rw-r--r--   1 root     root       281572 Jul 30  1995 zImage-1.2.11
-rw-r--r--   1 root     root       277476 Apr  1  1995 zImage-1.2.2


Andries

Re: support of older compilers

[Linus Torvalds]

On Fri, 5 Nov 2004, Andries Brouwer wrote:
>
> [Ob l-k]
> 
> I have not yet investigated, but my (vanilla) 2.6.9
> has a mouse problem that my vanilla 2.6.8.1 does not have:
> it starts selecting text as soon as I touch it for the first
> time, as if the initialization created a fake mouse-down event.

USB? We have another bug that was just root-caused to USB initialization 
sending a "clear suspend" packet, which apparently confuses some devices.

> [old stuff]
> 
> > There are probably people even using linux-1.2.
> 
> # uname -a
> Linux knuth 1.2.11 #27 Sun Jul 30 03:39:01 MET DST 1995 i486
> 
> (486 DX/2, 66MHz, 8 MB)
> 
> -rw-r--r--   1 root     root       281572 Jul 30  1995 zImage-1.2.11
> -rw-r--r--   1 root     root       277476 Apr  1  1995 zImage-1.2.2

Ok, you da man. What do you use it for? Or is it just lying around for 
nostalgic reasons?

		Linus

Re: support of older compilers

[Arjan van de Ven]

On Fri, 2004-11-05 at 07:41 -0800, Linus Torvalds wrote:
> > -rw-r--r--   1 root     root       281572 Jul 30  1995 zImage-1.2.11
> > -rw-r--r--   1 root     root       277476 Apr  1  1995 zImage-1.2.2
> 
> Ok, you da man. What do you use it for? Or is it just lying around for 
> nostalgic reasons?

some people are just a bit stubborn in accepting elf binaries perhaps ;)

Re: support of older compilers

[linux-os]

On Fri, 5 Nov 2004, Arjan van de Ven wrote:

> On Fri, 2004-11-05 at 07:41 -0800, Linus Torvalds wrote:
>>> -rw-r--r--   1 root     root       281572 Jul 30  1995 zImage-1.2.11
>>> -rw-r--r--   1 root     root       277476 Apr  1  1995 zImage-1.2.2
>>
>> Ok, you da man. What do you use it for? Or is it just lying around for
>> nostalgic reasons?
>
> some people are just a bit stubborn in accepting elf binaries perhaps ;)

Most of the tools on this machine were built on this machine:

Script started on Fri 05 Nov 2004 11:02:59 AM EST
# ls -la
total 112
drwxr-xr-x   2 root root  4096 Nov  5 11:02 .
drwxr-xr-x  12 root root  4096 Oct 22  1997 ..
-rw-r--r--   1 root root  7433 Aug 23  1994 lpr.1
-rw-r--r--   1 root root 16776 Oct 22  1997 lpr.c
-rw-r--r--   1 root root 16614 Jul 29  1996 lpr.c~
-rw-r--r--   1 root root 16712 Nov 24  1996 lpr.c.orig
-rw-r--r--   1 root root 31948 Dec 17  1993 lpr.termios
-rw-r--r--   1 root root   188 Oct 25  1994 Makefile
# pwd
/home/project/usr/src/lpr-5.9/lpr
# exit
exit
Script done on Fri 05 Nov 2004 11:03:12 AM EST

I would modify the BSD source so it would compile and run
on Linux, then I would submit it. You can see, above that
`lpr` had to get modified in 1996 to accommodate some
changes (probably GCC changes).

I save all this to show that there isn't a GNU/Linux, really
a BSD/Linux.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by John Ashcroft.
                  98.36% of all statistics are fiction.

Re: support of older compilers

[Chris Wedgwood]

On Fri, Nov 05, 2004 at 07:41:03AM -0800, Linus Torvalds wrote:

> > -rw-r--r--   1 root     root       281572 Jul 30  1995 zImage-1.2.11
> > -rw-r--r--   1 root     root       277476 Apr  1  1995 zImage-1.2.2

> Ok, you da man. What do you use it for? Or is it just lying around
> for nostalgic reasons?

to remind us how large the kernel is getting? :)

Re: support of older compilers

[Linus Torvalds]

On Fri, 5 Nov 2004, Chris Wedgwood wrote:

> On Fri, Nov 05, 2004 at 07:41:03AM -0800, Linus Torvalds wrote:
> 
> > > -rw-r--r--   1 root     root       281572 Jul 30  1995 zImage-1.2.11
> > > -rw-r--r--   1 root     root       277476 Apr  1  1995 zImage-1.2.2
> 
> > Ok, you da man. What do you use it for? Or is it just lying around
> > for nostalgic reasons?
> 
> to remind us how large the kernel is getting? :)

Yeah, I know. Damn, it's scary. We should probably have some
per-object-file statistics, and try to make people more aware of big bad
things.

The kernel does do more these days than it did in '95. But 6 times more? I 
dunno..

		Linus

Re: support of older compilers

[Grzegorz Kulewski]

> The kernel does do more these days than it did in '95. But 6 times more? I
> dunno..

Can't we remove ramfs for a good start? Everyone should use tmpfs instead 
and some stupid distributions (I will not tell their names) try to mount 
ramfs on /dev (udev) and that leads to very stupid panic if you will 
write for example:

dd if=/dev/evms/sda5 of=/dev/sda17 bs=1024

instead of "of=/dev/evms/sda17".

Explanation (if anybody needs one):
Kernel can't create more partition devices than 15 for SCSI and SATA disks 
because of lack of minor numbers. So I am using evms to create these 
devices. So I should use /dev/evms/sda* for these partitions. And if I 
will not remember to do so then I will get oom panic very shortly because 
ramfs is not limited (in contrary to tmpfs).

And this kind of stupid mistake can happen. It happened to me 3 times in a 
row before I started to debug what is wrong with this kernel.

[BTW. Does somebody know how to tell the kernel that I do not want 
/dev/sda[0-9]* files (but I do want /dev/hda files) created == I do not 
want kernel partition driver to touch this particular device?]

And using ramfs for anything else can easily lead to similar problems. So 
I think we do not need ramfs. Am I wrong? [I understand that removing it 
will not remove much code.]


Thanks,

Grzegorz Kulewski

Re: support of older compilers

[Linus Torvalds]

On Fri, 5 Nov 2004, Grzegorz Kulewski wrote:
> 
> And using ramfs for anything else can easily lead to similar problems. So 
> I think we do not need ramfs. Am I wrong? [I understand that removing it 
> will not remove much code.]

ramfs is very useful as a minimal filesystem for showing what the VFS
interfaces are, and also (I believe) used in embedded environments, where
it's simply the smallest possible thing, and swap isn't available anyway.

You can just disable it if you don't want it..

		Linus

[PATCH] change Kconfig entry for RAMFS (Was: Re: support of older compilers)

[Grzegorz Kulewski]

On Fri, 5 Nov 2004, Linus Torvalds wrote:
> On Fri, 5 Nov 2004, Grzegorz Kulewski wrote:
>>
>> And using ramfs for anything else can easily lead to similar problems. So
>> I think we do not need ramfs. Am I wrong? [I understand that removing it
>> will not remove much code.]
>
> ramfs is very useful as a minimal filesystem for showing what the VFS
> interfaces are, and also (I believe) used in embedded environments, where
> it's simply the smallest possible thing, and swap isn't available anyway.
>
> You can just disable it if you don't want it..

Probably, but it looks like it does not display in menuconfig and it is 
set by default. I understand that it is a good example, but it should be 
disabled by default I think... Or at least it should show in menuconfig. 
And I do not know why embedded environments want to use ramfs more 
than tmpfs. Swap is not needed for tmpfs and even if device has no swap it 
can be oomed because of ramfs too.


Will you accept this patch:

Signed-off-by: Grzegorz Kulewski <kangur@polcom.net>

--- linux/fs/Kconfig	 2004-11-05 23:14:27.297548136 +0100
+++ linux-gk/fs/Kconfig	 2004-11-05 23:23:09.365181792 +0100
@@ -929,8 +929,8 @@
         def_bool HUGETLBFS

  config RAMFS
-       bool
-       default y
+       bool "Ramfs file system support (PROBABLY USE TMPFS INSTEAD)"
+       default n
         ---help---
           Ramfs is a file system which keeps all files in RAM. It allows
           read and write access.
@@ -939,8 +939,8 @@
           you need a file system which lives in RAM with limit checking use
           tmpfs.

-         To compile this as a module, choose M here: the module will be called
-         ramfs.
+         WARNING: If you will place too many data on this filesystem,
+         the kernel will panic because of OOM! Use tmpfs instead if you can.

  source "fs/supermount/Kconfig"

-

I think that RAMFS can not be build as a module becuse it is marked bool. 
Am I wrong?

If you will apply this it will be my first kernel patch in mainline. Wow! 
:-)

Because of this reason please do not complain too loud if something is 
not ok with this patch. I am inexperienced in producing and sending 
patches for inclusion into Linux. If this patch is broken or you do not 
want to apply it in this form, I will be more than happy to fix it of 
course.


Thanks,

Grzegorz Kulewski

Re: [PATCH] change Kconfig entry for RAMFS (Was: Re: support of older compilers)

[Linus Torvalds]

On Sat, 6 Nov 2004, Grzegorz Kulewski wrote:
> 
> Probably, but it looks like it does not display in menuconfig and it is 
> set by default. I understand that it is a good example, but it should be 
> disabled by default I think... Or at least it should show in menuconfig. 
> And I do not know why embedded environments want to use ramfs more 
> than tmpfs. Swap is not needed for tmpfs and even if device has no swap it 
> can be oomed because of ramfs too.

Ehh. tmpfs _is_ ramfs in the embedded world. Take a look into 
mm/tiny-shmem.c, notice how it just calls it tmpfs and uses ramfs.

> Will you accept this patch:

Nope. See above. You're breaking a dependency here.

So at the very least you'd need to make the Kconfig understand the 
dependency on ramfs.

Also, don't shout in help-files. Nobody likes shouting. 

		Linus

Re: [PATCH] change Kconfig entry for RAMFS

[Grzegorz Kulewski]

> So at the very least you'd need to make the Kconfig understand the
> dependency on ramfs.

Should I add dependency to tmpfs on ramfs when building for embedded? Or 
should I introduce new config option to stop registering ramfs as a 
mountable filesystem?


> Also, don't shout in help-files. Nobody likes shouting.

Sorry.

For now, will you accept this patch:

Signed-off-by: Grzegorz Kulewski <kangur@polcom.net>

--- linux/fs/Kconfig	 2004-10-20 19:48:27.000000000 +0200
+++ linux-gk/fs/Kconfig	 2004-11-05 23:58:56.745730328 +0100
@@ -939,9 +939,6 @@
           you need a file system which lives in RAM with limit checking use
           tmpfs.

-         To compile this as a module, choose M here: the module will be called
-         ramfs.
-
  source "fs/supermount/Kconfig"

  endmenu
-


Thanks,

Grzegorz Kulewski

Re: [PATCH] change Kconfig entry for RAMFS

[Grzegorz Kulewski]

Oh, I am stupid. As DaMouse pointed out I diffed against wrong kernel 
(-cko2 instead vanilla). Sorry. Here is updated patch:

Signed-off-by: Grzegorz Kulewski <kangur@polcom.net>

--- linux-2.6.9/fs/Kconfig	 2004-11-06 01:11:58.900541536 +0100
+++ linux-2.6.9-gk/fs/Kconfig	 2004-11-06 01:13:04.432579152 +0100
@@ -937,9 +937,6 @@
           you need a file system which lives in RAM with limit checking use
           tmpfs.

-         To compile this as a module, choose M here: the module will be called
-         ramfs.
-
  endmenu

  menu "Miscellaneous filesystems"
-

I hope it is good now. And I hope my mailer doesn't destroy the patch?


Thanks,

Grzegorz Kulewski

Re: [PATCH] change Kconfig entry for RAMFS

[Matt Mackall]

On Sat, Nov 06, 2004 at 12:44:14AM +0100, Grzegorz Kulewski wrote:
> >So at the very least you'd need to make the Kconfig understand the
> >dependency on ramfs.
> 
> Should I add dependency to tmpfs on ramfs when building for embedded? Or 
> should I introduce new config option to stop registering ramfs as a 
> mountable filesystem?

Root is ramfs at early boot time, making it optional is tricky.

-- 
Mathematics is the supreme nostalgia of our time.

Re: [PATCH] change Kconfig entry for RAMFS

[Grzegorz Kulewski]

On Tue, 9 Nov 2004, Matt Mackall wrote:

> On Sat, Nov 06, 2004 at 12:44:14AM +0100, Grzegorz Kulewski wrote:
>>> So at the very least you'd need to make the Kconfig understand the
>>> dependency on ramfs.
>>
>> Should I add dependency to tmpfs on ramfs when building for embedded? Or
>> should I introduce new config option to stop registering ramfs as a
>> mountable filesystem?
>
> Root is ramfs at early boot time, making it optional is tricky.

You mean it is

rootfs / rootfs rw 0 0

in my /proc/mounts? Why this can not be tmpfs on normal dektop or server 
machines?

I have two goals in removing ramfs:
- stop user or distribution from mounting it somewhere to avoid strange 
oom panics when, by some unkown reason, something writes more data on it 
than RAM in the box,
- maybe construct / on tmpfs (from initramfs => "inittmpfs") in the 
future. Then ramfs will mount all needed filesystem (possibly from net or 
some sophisticated compressed / encrypted / raid volumes. But I will want 
/ on tmpfs to stay, just mount --bind /mnt/root/bin /bin and the same for 
other / directories. This way I can mount /proc, /sys, create /dev for 
udev and so on once, and I think this is simpler than mounting some real 
fs latter on / or using pivot_root. This way I can survive some serious fs 
problems on real disk / because I can umount it (maybe in single mode) and 
run some fs checker from my inittmpfs on it. I do not want to use ramfs 
for that because it can oom when some program or I will write big file to 
/.

I really do not understand why we need ramfs on not embedded boxes. If we 
can not remove its code then at least make in impossible to mount. But 
that is only my opinion.


Thanks,

Grzegorz Kulewski

Re: [PATCH] change Kconfig entry for RAMFS

[Bill Davidsen]

Matt Mackall wrote:
> On Sat, Nov 06, 2004 at 12:44:14AM +0100, Grzegorz Kulewski wrote:
> 
>>>So at the very least you'd need to make the Kconfig understand the
>>>dependency on ramfs.
>>
>>Should I add dependency to tmpfs on ramfs when building for embedded? Or 
>>should I introduce new config option to stop registering ramfs as a 
>>mountable filesystem?
> 
> 
> Root is ramfs at early boot time, making it optional is tricky.
> 
Other than not being able to boot the system, would there be any other 
problems? ;-)

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: [PATCH] change Kconfig entry for RAMFS (Was: Re: support of older compilers)

[DaMouse]

On Sat, 6 Nov 2004 00:02:22 +0100 (CET), Grzegorz Kulewski
<kangur@polcom.net> wrote:
>   source "fs/supermount/Kconfig"

what version of the kernel are you patching against that requires
supermount? perhaps it would be better for you to make it against
mainline or -mm for easier patching :)

-DaMouse


-- 
I know I broke SOMETHING but its their fault for not fixing it before me

Re: [PATCH] change Kconfig entry for RAMFS (Was: Re: support of older compilers)

[Grzegorz Kulewski]

On Fri, 5 Nov 2004, DaMouse wrote:

> On Sat, 6 Nov 2004 00:02:22 +0100 (CET), Grzegorz Kulewski
> <kangur@polcom.net> wrote:
>>   source "fs/supermount/Kconfig"
>
> what version of the kernel are you patching against that requires
> supermount? perhaps it would be better for you to make it against
> mainline or -mm for easier patching :)

Oh, sorry... I forgot that not everyone uses -cko kernels. But they 
should. :-)

I should start producing more patches into mainline I think. :-)


Thanks,

Grzegorz Kulewski

Re: [PATCH] change Kconfig entry for RAMFS (Was: Re: support of older compilers)

[DaMouse]

Maybe this one would be more suitable?

http://kernel.damouse.co.uk/RAMFS.patch

-DaMouse


On Sat, 6 Nov 2004 00:49:20 +0100 (CET), Grzegorz Kulewski
<kangur@polcom.net> wrote:
> On Fri, 5 Nov 2004, DaMouse wrote:
> 
> > On Sat, 6 Nov 2004 00:02:22 +0100 (CET), Grzegorz Kulewski
> > <kangur@polcom.net> wrote:
> >>   source "fs/supermount/Kconfig"
> >
> > what version of the kernel are you patching against that requires
> > supermount? perhaps it would be better for you to make it against
> > mainline or -mm for easier patching :)
> 
> Oh, sorry... I forgot that not everyone uses -cko kernels. But they
> should. :-)
> 
> I should start producing more patches into mainline I think. :-)
> 
> Thanks,
> 
> Grzegorz Kulewski
> 
> 


-- 
I know I broke SOMETHING but its their fault for not fixing it before me

RE: support of older compilers

[Hua Zhong]

At least in 2.4.17 I couldn't loopback mount an (ext2) image from tmpfs and
had to use ramfs. Has this been fixed?

> > The kernel does do more these days than it did in '95. But 
> 6 times more? I
> > dunno..
> 
> Can't we remove ramfs for a good start? Everyone should use 
> tmpfs instead 
> and some stupid distributions (I will not tell their names) 
> try to mount 
> ramfs on /dev (udev) and that leads to very stupid panic if you will 
> write for example:
> 
> dd if=/dev/evms/sda5 of=/dev/sda17 bs=1024
> 
> instead of "of=/dev/evms/sda17".
> 
> Explanation (if anybody needs one):
> Kernel can't create more partition devices than 15 for SCSI 
> and SATA disks 
> because of lack of minor numbers. So I am using evms to create these 
> devices. So I should use /dev/evms/sda* for these partitions. 
> And if I 
> will not remember to do so then I will get oom panic very 
> shortly because 
> ramfs is not limited (in contrary to tmpfs).
> 
> And this kind of stupid mistake can happen. It happened to me 
> 3 times in a 
> row before I started to debug what is wrong with this kernel.
> 
> [BTW. Does somebody know how to tell the kernel that I do not want 
> /dev/sda[0-9]* files (but I do want /dev/hda files) created 
> == I do not 
> want kernel partition driver to touch this particular device?]
> 
> And using ramfs for anything else can easily lead to similar 
> problems. So 
> I think we do not need ramfs. Am I wrong? [I understand that 
> removing it 
> will not remove much code.]
> 
> 
> Thanks,
> 
> Grzegorz Kulewski
> 
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: support of older compilers

[Willy Tarreau]

On Fri, Nov 05, 2004 at 02:08:45PM -0800, Hua Zhong wrote:
> At least in 2.4.17 I couldn't loopback mount an (ext2) image from tmpfs and
> had to use ramfs. Has this been fixed?

I believe it works now (2.4.27) but at least some external add-ons such as
Tux cannot serve pages on tmpfs but are OK on ramfs. What would be needed
is a ramfs with a size limit.

Willy

Re: support of older compilers

[Hugh Dickins]

On Sat, 6 Nov 2004, Willy Tarreau wrote:
> On Fri, Nov 05, 2004 at 02:08:45PM -0800, Hua Zhong wrote:
> > At least in 2.4.17 I couldn't loopback mount an (ext2) image from tmpfs and
> > had to use ramfs. Has this been fixed?

Yes, fixed in 2.4.22.

> I believe it works now (2.4.27) but at least some external add-ons such as
> Tux cannot serve pages on tmpfs but are OK on ramfs.

Oh, I thought that was fixed at the same time in 2.4.22.
Seems nobody complained it wasn't.  Probably easily done,
but really too late now to be adding features to 2.4.
The 2.6 tmpfs has no problem there, does it?

Hugh

Re: support of older compilers

[Willy Tarreau]

On Sat, Nov 06, 2004 at 09:43:57AM +0000, Hugh Dickins wrote:
> On Sat, 6 Nov 2004, Willy Tarreau wrote:
> > On Fri, Nov 05, 2004 at 02:08:45PM -0800, Hua Zhong wrote:
> > > At least in 2.4.17 I couldn't loopback mount an (ext2) image from tmpfs and
> > > had to use ramfs. Has this been fixed?
> 
> Yes, fixed in 2.4.22.
> 
> > I believe it works now (2.4.27) but at least some external add-ons such as
> > Tux cannot serve pages on tmpfs but are OK on ramfs.
> 
> Oh, I thought that was fixed at the same time in 2.4.22.
> Seems nobody complained it wasn't.  Probably easily done,
> but really too late now to be adding features to 2.4.

I don't understand what causes the problem, otherwise I would have been
happy to propose a patch.

> The 2.6 tmpfs has no problem there, does it?

I don't know. I essentially use tux as a target for network stress testing,
and since 2.6 is a lot slower in this area, I have not done extensive tests.

Cheers,
Willy

Re: support of older compilers [u]

[Martin Schlemmer [c]]

[-- Attachment #1: Type: text/plain, Size: 2749 bytes --]

On Fri, 2004-11-05 at 22:59 +0100, Grzegorz Kulewski wrote:
> > The kernel does do more these days than it did in '95. But 6 times more? I
> > dunno..
> 
> Can't we remove ramfs for a good start? Everyone should use tmpfs instead 
> and some stupid distributions (I will not tell their names) try to mount 
> ramfs on /dev (udev) and that leads to very stupid panic if you will 
> write for example:
> 
> dd if=/dev/evms/sda5 of=/dev/sda17 bs=1024
> 
> instead of "of=/dev/evms/sda17".
> 
> Explanation (if anybody needs one):
> Kernel can't create more partition devices than 15 for SCSI and SATA disks 
> because of lack of minor numbers. So I am using evms to create these 
> devices. So I should use /dev/evms/sda* for these partitions. And if I 
> will not remember to do so then I will get oom panic very shortly because 
> ramfs is not limited (in contrary to tmpfs).
> 
> And this kind of stupid mistake can happen. It happened to me 3 times in a 
> row before I started to debug what is wrong with this kernel.
> 
> [BTW. Does somebody know how to tell the kernel that I do not want 
> /dev/sda[0-9]* files (but I do want /dev/hda files) created == I do not 
> want kernel partition driver to touch this particular device?]
> 

So basically /dev/sda* have major of scsi, and /dev/evms/sda* have major
of evms, and you end up using the wrong nodes?  This sounds more like
a udev-ruleset problem (not something that will be easy to get right
with a generic one I imagine), rather than anything remotely to do with
ramfs.  If you changed the scripts to use tmpfs rather, you would have
gotten the same result.

Now I do not know evms, so you are on your own there, but here is my
rules for dm and a similar issue:

---------
nosferatu linux-2.6-bk # cat /etc/udev/rules.d/30-sda.rules
KERNEL="sda[0-9]*", NAME=""
nosferatu linux-2.6-bk # cat /etc/udev/rules.d/40-dm.rules
KERNEL="dm-[0-9]*", PROGRAM="/sbin/devmap_name %M %m", NAME="mapper/%c", SYMLINK="%c"
nosferatu linux-2.6-bk #

---------

(note that they should be before all the others if you only have one
rule file)

So basically for the real scsi devices (you could add a BUS="scsi" to
make sure I guess) matching 'sda[0-9]*' no node will be created, and I
get my /dev/mapper/* nodes, with a symlink in /dev/ making things
easier.

you could have a rule catching all evms devices, and then add
the /dev/sda* symlinks, perhaps like so:

--------
KERNEL="evms/sda[0-9]*", SYMLINK="sda%n"
--------

Note that I do not know if a rule was needed to get the nodes in
/dev/evms/ in the first place (due to my admitted lack of evms knowledge
above), so you might have to modify an existing rule ...

-- 
Martin Schlemmer


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: support of older compilers [u]

[Grzegorz Kulewski]

On Sat, 6 Nov 2004, Martin Schlemmer [c] wrote:

> On Fri, 2004-11-05 at 22:59 +0100, Grzegorz Kulewski wrote:
>>> The kernel does do more these days than it did in '95. But 6 times more? I
>>> dunno..
>>
>> Can't we remove ramfs for a good start? Everyone should use tmpfs instead
>> and some stupid distributions (I will not tell their names) try to mount
>> ramfs on /dev (udev) and that leads to very stupid panic if you will
>> write for example:
>>
>> dd if=/dev/evms/sda5 of=/dev/sda17 bs=1024
>>
>> instead of "of=/dev/evms/sda17".
>>
>> Explanation (if anybody needs one):
>> Kernel can't create more partition devices than 15 for SCSI and SATA disks
>> because of lack of minor numbers. So I am using evms to create these
>> devices. So I should use /dev/evms/sda* for these partitions. And if I
>> will not remember to do so then I will get oom panic very shortly because
>> ramfs is not limited (in contrary to tmpfs).
>>
>> And this kind of stupid mistake can happen. It happened to me 3 times in a
>> row before I started to debug what is wrong with this kernel.
>>
>> [BTW. Does somebody know how to tell the kernel that I do not want
>> /dev/sda[0-9]* files (but I do want /dev/hda files) created == I do not
>> want kernel partition driver to touch this particular device?]
>>
>
> So basically /dev/sda* have major of scsi, and /dev/evms/sda* have major
> of evms, and you end up using the wrong nodes?

Not exactly. I end up creating really big, growing, file on no limit RAM 
backed filesystem. EVMS locks standard devices, so I probably can not run 
something like:

dd if=/dev/sda5 of=/dev/sda6 bs=1024

because it will return "device busy" error or something like that. But I 
didn't test it. But I tested (in the most painful way) that

mount -t ext2 /dev/sda5 /mnt/foo

will not work because of this error.

And EVMS has no major numbers. It is purely user space. It uses 
device-mapper for creating devices and uses device-mapper's major number.

And yes, I probably can force UDEV to stop creating /dev/sda[0-9]* 
devices, but this is not the right solution I think. These config files 
are managed by my distribution and are complicated. I do not want to have 
to merge them with updates every time new UDEV is released. Besides I want 
to disable kernel partition discovery just for this device. This will be 
ugly excaption.


Thanks,

Grzegorz Kulewski

Re: support of older compilers [u]

[chibiryuu]

> And yes, I probably can force UDEV to stop creating /dev/sda[0-9]*
> devices, but this is not the right solution I think. These config files
> are managed by my distribution and are complicated. I do not want to have
> to merge them with updates every time new UDEV is released. Besides I want
> to disable kernel partition discovery just for this device. This will be
> ugly excaption.

You can just place a file in /etc/udev/rules.d; your distribution may
have files (50-udev.rules) in there already, but if you create a file
which is lexically before them (10-local.rules), rules in it will take
precedence -- well, be parsed first -- and your distribution should
not overwrite your file.

Re: support of older compilers

[Andries Brouwer]

# > > There are probably people even using linux-1.2.
# > 
# > # uname -a
# > Linux knuth 1.2.11 #27 Sun Jul 30 03:39:01 MET DST 1995 i486
# > 
# > (486 DX/2, 66MHz, 8 MB)
# > 
# > -rw-r--r--   1 root     root       281572 Jul 30  1995 zImage-1.2.11
# > -rw-r--r--   1 root     root       277476 Apr  1  1995 zImage-1.2.2
# 
# Ok, you da man. What do you use it for? Or is it just lying around for 
# nostalgic reasons?

One strength is the fact that it boots in a couple of seconds, while
my current 2.6.9 with vendor boot scripts takes minutes.
Another strength is the weight - exactly 2 kg.
I write letters, papers, lecture notes and stuff.
It feels faster than modern machines.
Only need X, TeX, emacs and rsh, rcp.

>> to remind us how large the kernel is getting? :)

> Yeah, I know. Damn, it's scary.
> The kernel does do more these days than it did in '95. But 6 times more?

I recall the times where 4K was enough for a multiuser OS that provided
each user its own virtual machine (and could run itself under itself).
Small is beautiful. Six times? Today for me is

-rw-r--r--  1 aeb users 3161708 2004-11-06 01:19 /boot/bzImage-2.6.9test

Probably I select more filesystems than you do.

Andries

Re: support of older compilers

[Linus Torvalds]

On Sat, 6 Nov 2004, Andries Brouwer wrote:
> 
> -rw-r--r--  1 aeb users 3161708 2004-11-06 01:19 /boot/bzImage-2.6.9test
> 
> Probably I select more filesystems than you do.

Ugh, you're right. Doing a reasonably normal build without modules nets us

	  205K mm/built-in.o                                            
	  336K kernel/built-in.o                                            
	  451K sound/built-in.o                                            
	  864K net/built-in.o                                            
	 1016K fs/built-in.o                                            
	  2.3M drivers/built-in.o                                            

which is kind of scary. Of course, in the drivers, about half a meg of
that is just the PCI name translation, so some of it is trivial (and
thrown away at boot), but most of it is just spread out in fat all over. 

It's hard to go on a diet.

		Linus

Re: support of older compilers

[Adrian Bunk]

On Sat, Nov 06, 2004 at 09:33:35AM -0800, Linus Torvalds wrote:
> 
> 
> On Sat, 6 Nov 2004, Andries Brouwer wrote:
> > 
> > -rw-r--r--  1 aeb users 3161708 2004-11-06 01:19 /boot/bzImage-2.6.9test
> > 
> > Probably I select more filesystems than you do.
> 
> Ugh, you're right. Doing a reasonably normal build without modules nets us
> 
> 	  205K mm/built-in.o                                            
> 	  336K kernel/built-in.o                                            
> 	  451K sound/built-in.o                                            
> 	  864K net/built-in.o                                            
> 	 1016K fs/built-in.o                                            
> 	  2.3M drivers/built-in.o                                            
> 
> which is kind of scary. Of course, in the drivers, about half a meg of
> that is just the PCI name translation, so some of it is trivial (and
> thrown away at boot), but most of it is just spread out in fat all over. 
> 
> It's hard to go on a diet.

It's even harder because some subsystem maintainers refuse to remove 
unused global functions that might be used at some point far in the 
future or that even are never intended for in-kernel usage...

> 		Linus

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

bloat

[Andries Brouwer]

On Sat, Nov 06, 2004 at 08:36:08PM +0100, Adrian Bunk wrote:

> It's even harder because some subsystem maintainers refuse to remove 
> unused global functions that might be used at some point far in the 
> future or that even are never intended for in-kernel usage...

I have one or two unused functions inside #if 0 in sddr09.c.
Finding out the proper hardware details was nontrivial,
it would be a pity to throw the knowledge away.
But of course there is never a reason to have an unused function
appear in the binary. It is only source bloat.

Andries

Re: bloat

[Adrian Bunk]

On Sat, Nov 06, 2004 at 10:41:47PM +0100, Andries Brouwer wrote:
> On Sat, Nov 06, 2004 at 08:36:08PM +0100, Adrian Bunk wrote:
> 
> > It's even harder because some subsystem maintainers refuse to remove 
> > unused global functions that might be used at some point far in the 
> > future or that even are never intended for in-kernel usage...
> 
> I have one or two unused functions inside #if 0 in sddr09.c.
> Finding out the proper hardware details was nontrivial,
> it would be a pity to throw the knowledge away.
> But of course there is never a reason to have an unused function
> appear in the binary. It is only source bloat.

No disagreement on this issue.

But unused global functions that are even EXPORT_SYMBOL'ed like in the 
ACPI and FireWire cases are not only source bloat...

> Andries

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: bloat

[Arnaldo Carvalho de Melo]

Adrian Bunk wrote:
> On Sat, Nov 06, 2004 at 10:41:47PM +0100, Andries Brouwer wrote:
> 
>>On Sat, Nov 06, 2004 at 08:36:08PM +0100, Adrian Bunk wrote:
>>
>>
>>>It's even harder because some subsystem maintainers refuse to remove 
>>>unused global functions that might be used at some point far in the 
>>>future or that even are never intended for in-kernel usage...
>>
>>I have one or two unused functions inside #if 0 in sddr09.c.
>>Finding out the proper hardware details was nontrivial,
>>it would be a pity to throw the knowledge away.
>>But of course there is never a reason to have an unused function
>>appear in the binary. It is only source bloat.
> 
> 
> No disagreement on this issue.
> 
> But unused global functions that are even EXPORT_SYMBOL'ed like in the 
> ACPI and FireWire cases are not only source bloat...

I agree with Andries that a reasonably small number of lines with
Pure Bloat (aka, not used at all) can stay as source bloat, #ifdefed,
but disagree on it getting lost if removed from the kernel, these days
once something gets in the kernel for at least one release it can be
fairly considered written in stone, with so many mirrors, source
navigation sites, search engines that open all kinds of files looking
for any sequence of letters or even pictures, sounds, etc.

Some years ago, when working with IPX I thought about looking at
finishing Jay Schullist initial work on SPX, but after some time I
just gave up and deleted the thing from mainline, but it is easly
retrievable in case somebody has any kind of interest.

Regards,

- Arnaldo

PS.: Bitrotting is just a small side effect, of course 8)

Re: bloat

[Frank van Maarseveen]

On Sat, Nov 06, 2004 at 10:41:47PM +0100, Andries Brouwer wrote:
> 
> I have one or two unused functions inside #if 0 in sddr09.c.
> Finding out the proper hardware details was nontrivial,
> it would be a pity to throw the knowledge away.

Of course nobody likes to throw away hard work. However, code that isn't
used tends to be unmaintained. So it might be outdated when (and if)
it gets used in the future. A web page indexed by search engines is a
excellent way to preserve knowledge.

The existence of unused code in the kernel will probably make not much
of a difference for future development. But it pollutes the source so
IMHO we could do without many of these:

$ find -name '*.[ch]' |xargs grep '^#if 0'|wc
   2491    7202   97634					(2.6.9-rc3)

-- 
Frank

Re: support of older compilers

[Willy Tarreau]

On Thu, Nov 04, 2004 at 05:39:08PM -0600, Adam Heath wrote:
 
> Using an old version of gcc because it is faster at compiling is a
> non-argument.

If you can send to all of us for free some hardware which is twice as fast
as what we have, which does not generate more heat and noise, then perhaps
most of us will accept to use a twice as slow compiler. But not for long,
since some may realize that they can produce quality code twice as fast on
their new system ;-)

At least, with fast machines and fast compilers, people have no excuse not
testing the patches they send. A few years ago, broken & non-tested patches
were very common. This could become standard again if everyone jumped into
gcc 3.4 unconditionnaly.

> If they produce bad code, then that's a valid reason.
> If they produce larger code, that is a valid reason.

You can also ask the gcc people when they will decide to write a new version
which is able to compile some code which compiles with the previous release.
I have some tools which don't compile anymore with gcc 3 and error messages
look more like insults than information, and I don't even know how to "fix"
(adapt ?) them. This too is a valid reason to stick to older compilers.

Willy

Re: support of older compilers

[Adam Heath]

On Fri, 5 Nov 2004, Willy Tarreau wrote:

> On Thu, Nov 04, 2004 at 05:39:08PM -0600, Adam Heath wrote:
>
> > Using an old version of gcc because it is faster at compiling is a
> > non-argument.
>
> If you can send to all of us for free some hardware which is twice as fast
> as what we have, which does not generate more heat and noise, then perhaps
> most of us will accept to use a twice as slow compiler. But not for long,
> since some may realize that they can produce quality code twice as fast on
> their new system ;-)
>
> At least, with fast machines and fast compilers, people have no excuse not
> testing the patches they send. A few years ago, broken & non-tested patches
> were very common. This could become standard again if everyone jumped into
> gcc 3.4 unconditionnaly.

My argument started when people starting complaining about new compilers being
slow, and using that as the only reason to not use them.

A single datapoint by itself can not be used in an argument here.

You are adding additional requirements(using older hardware), as that makes
the argument valid.

> > If they produce bad code, then that's a valid reason.
> > If they produce larger code, that is a valid reason.
>
> You can also ask the gcc people when they will decide to write a new version
> which is able to compile some code which compiles with the previous release.
> I have some tools which don't compile anymore with gcc 3 and error messages
> look more like insults than information, and I don't even know how to "fix"
> (adapt ?) them. This too is a valid reason to stick to older compilers.

Not always.  Older gccs accepted bad code; you can't honestly expect newer
ones to always accept this bad code.

Note: I'm not saying that's the specific case here.

Re: support of older compilers

[Martin J. Bligh]

>> > I didn't deny the speed difference of older and newer compilers.
>> > 
>> > But why is this an issue when compiling a kernel?  How often do you compile
>> > your kernel?
>> 
>> First off, for some people that is literally where _most_ of the CPU
>> cycles go.
> 
> So find a fast machine.  As I have already said, you don't need to compile a
> kernel for a slow machine/arch *on* a slow machine/arch.
> 
>> Second, it's not just that the compilers are slower. Historically, new gcc
>> versions are:
>>  - slower
> 
> Again, that's a straw man.
> 
>>  - generate worse code
>>  - buggier
> 
> I don't doubt these are issues.  That's not what I am discussing.

Ummm. you asked why people don't use newer compilers, you were told exactly
why. How is that not what you're discussing?

Not breaking older compilers takes very little effort in practice. Why the
hell would you want to break compilation with then?

M.

Re: support of older compilers

[Bill Davidsen]

Adam Heath wrote:
> On Wed, 3 Nov 2004, Chris Wedgwood wrote:
> 
> 
>>On Wed, Nov 03, 2004 at 05:06:56PM -0600, Adam Heath wrote:
>>
>>
>>>You can't be serious that this is a problem.
>>
>>try it, say gcc 2.95 vs gcc 4.0 ... i think last i checked the older
>>gcc was over twice as fast
> 
> 
> I didn't deny the speed difference of older and newer compilers.
> 
> But why is this an issue when compiling a kernel?  How often do you compile
> your kernel?

Twice for each -bk to look for "not my fault" issues (preempt and not), 
usually once with some combination of Nick, Con, or Ingo patches, and 
then with config options depending on what's been added. Not to mention 
patches I cull from here and my own set of network patches.

For some people I bet the limit is 24/{compile_time} per day.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: support of older compilers

[Martin J. Bligh]

>> On Wed, Nov 03, 2004 at 04:02:49PM -0500, Timothy Miller wrote:
>> > I'm just curious about why there seems to be so much work going into
>> > supporting a wide range of GCC versions.  If people are willing to
>> > download and compile a new kernel (and migrating from 2.4 to 2.6 is
>> > non-trivial for some systems, like RH9), why aren't they willing to also
>> > download and build a new compiler?
>> 
>> Because the new compilers are a lot slower.
> 
> You can't be serious that this is a problem.

Yes, it is. Mostly they produce larger, slower code too.

M.

Re: support of older compilers

[Matti Aarnio]

On Wed, Nov 03, 2004 at 04:02:49PM -0500, Timothy Miller wrote:
> I'm just curious about why there seems to be so much work going into 
> supporting a wide range of GCC versions.  If people are willing to 
> download and compile a new kernel (and migrating from 2.4 to 2.6 is 
> non-trivial for some systems, like RH9), why aren't they willing to also 
> download and build a new compiler?


How about those other architectures, than i386 ?
Over the years I have learned, that while GCC may work OK in i386,
the same version used in SPARC does produce bad code.  This has
bitten me multiple times.


We weird people of other architechtures do tend to get "somewhat"
conservative over the years in finding, and finally staying with
a compiler that we have learned to work.   Multiple burned,
forever shy...

 /Matti Aarnio

Re: support of older compilers

[Giacomo A. Catenazzi]

Matti Aarnio wrote:
> On Wed, Nov 03, 2004 at 04:02:49PM -0500, Timothy Miller wrote:
> 
>>I'm just curious about why there seems to be so much work going into 
>>supporting a wide range of GCC versions.  If people are willing to 
>>download and compile a new kernel (and migrating from 2.4 to 2.6 is 
>>non-trivial for some systems, like RH9), why aren't they willing to also 
>>download and build a new compiler?
> 
> 
> 
> How about those other architectures, than i386 ?
> Over the years I have learned, that while GCC may work OK in i386,
> the same version used in SPARC does produce bad code.  This has
> bitten me multiple times.
> 
> 
> We weird people of other architechtures do tend to get "somewhat"
> conservative over the years in finding, and finally staying with
> a compiler that we have learned to work.   Multiple burned,
> forever shy...

But is it Linux the biggest compiler bug finder?
So forcing a newer compiler in other architectures should
improve also the quality of code generation.

ciao
	cate

Re: support of older compilers

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 543 bytes --]

On Wed, 03 Nov 2004 22:37:10 +0100, "Giacomo A. Catenazzi" said:

> But is it Linux the biggest compiler bug finder?
> So forcing a newer compiler in other architectures should
> improve also the quality of code generation.

However, the problem is that I probably want to compile a working
kernel *now*, not when the GCC people finally get around to fixing
the b0rkedness they added for my architecture in gcc 3.2.3.  So I
get to keep 3.2.2 around until it's fixed.  (Feel free to replace
3.2.3 with whatever arch-dependent value you like).


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: support of older compilers

[Miles Bader]

Valdis.Kletnieks@vt.edu writes:
> However, the problem is that I probably want to compile a working
> kernel *now*, not when the GCC people finally get around to fixing
> the b0rkedness they added for my architecture in gcc 3.2.3.

Yup, this is particuarly true with fringe architectures.

E.g., you're using a compiler for your CPU that has changes not in
mainstream gcc, the vendor who made them is slow in updating to new gcc
versions, and their changes are complex enough that you don't want to
spend the manpower to port them yourself.

You've got the GPL, so of course it's of course _possible_ to do the
work yourself and get a newer gcc working, but sometimes it's really
nice to also have the option _not_ to do that...

-Miles
-- 
((lambda (x) (list x x)) (lambda (x) (list x x)))

Re: support of older compilers

[Chris Wedgwood]

On Wed, Nov 03, 2004 at 10:37:10PM +0100, Giacomo A. Catenazzi wrote:

> But is it Linux the biggest compiler bug finder?

for C it might be, obviously not for C++

> So forcing a newer compiler in other architectures should
> improve also the quality of code generation.

assuming there are sufficiently many people to work on gcc and those
platforms (there isn't)