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?
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.
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
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)
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
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).
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)
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.
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
[email protected] 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)))
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?
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
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.
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.
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.
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.....
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.
On Thursday 04 Nov 2004 17:04, [email protected] 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
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!
>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?
It is not necessarily that they are unwilling,
it is a question of trust (in the output
of the compiler) and of the inconvenience of
multiple concurrent gcc version installations
(paths; hint: this needs to be simpler).
Example:
I've been using gcc-2.95.3 with a security-patched
glibc-2.2.5, and I wanted to upgrade to glibc-2.3.2
(lots of bugs gone and more Posix/SUS compliance
added in the years in between 2.2.5 and 2.3.2).
For that I needed gcc-3.x. So, in succession,
I downloaded and compiled gcc-3.3.2, 3.4.0, and 3.4.1,
against both glibc-2.2.5 and glibc-2.3.2, with the
latest binutils at the time (which works with any
of those compiler and glibc versions).
I found that none of the gcc 3.x versions could
correctly compile a construct like this
(independent of runtime glibc version):
file1.h:
/* header boilerplate to avoid multiple #includes of
the same file */
#define STR1 "string 1"
file2.c:
#include "file1.h"
const char * str2 = "whatever"STR1"stuff this\n\
string has in it"STR1" and so on ad infinitum\n\
"STR1"yada yada";
/* this was actually about 40 lines, maybe more,
with maybe 10 instances of "../"STR1"..." */
All of the gcc-3.x versions would bail with
an error trying to compile that str2 definition
in file2.c.
They didn't always fail on literal string
concatenation (IIRC some short ones compiled
ok), but they consistently failed to concatenate
literal strings correctly for some source
files that gcc-2.95.3 would compile correctly
every time.
(The glibc trees had distributor patches, so I filed
the bug report via their support, in order for
them to see whether their patches were responsible
for the error, assuming that they would forward
it on if not.)
In sum: for production code it doesn't matter
what all a new C compiler version can do that
the old one could not if it won't compile
quite ordinary standard C correctly.
"So what else is wrong with it that we
aren't seeing?"
It would be good to have bugs fixed in the
new compilers, because they obviously have
some advantages (I noticed that gcc-3.4.x
seemed quite a bit faster than 2.95.3 when
compiling glibc, and it would nice if as
no longer randomly choked on the x86 code
generated after using -fprofile-arcs and
-fbranch-probabilities, something that
occasionally happens with gcc-2.95.3).
But one does occasionally need to get some
other work done besides new compiler
development.
--
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm
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 <[email protected]> wrote:
> On Thursday 04 Nov 2004 17:04, [email protected] 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Thu, Nov 04, 2004 at 07:36:26PM +0000, Ian Hastie wrote:
> On Thursday 04 Nov 2004 17:04, [email protected] 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
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)
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.
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 ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
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
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.
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
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)).
>> 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.
Linus Torvalds wrote:
> 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?
Maybe because older gccs are not maintained, only 3.3.x 3.4.x and 4.0.0.
_Unless_ you have a long life time distribution (aka SLES, RHEL or clones).
--
TLOZ OOT: worse than drugs.
>> > 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.
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.
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
[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
On 4 Nov 2004, Clayton Weaver stated:
> I found that none of the gcc 3.x versions could
> correctly compile a construct like this
> (independent of runtime glibc version):
>
> file1.h:
>
> /* header boilerplate to avoid multiple #includes of
> the same file */
>
> #define STR1 "string 1"
>
> file2.c:
>
> #include "file1.h"
>
> const char * str2 = "whatever"STR1"stuff this\n\
> string has in it"STR1" and so on ad infinitum\n\
> "STR1"yada yada";
>
> /* this was actually about 40 lines, maybe more,
> with maybe 10 instances of "../"STR1"..." */
>
> All of the gcc-3.x versions would bail with
> an error trying to compile that str2 definition
> in file2.c.
And do I see any bug reports from you in GCC bugzilla? I do not (not
under the name `Clayton Weaver', anyway).
Further, the code you provide works in all the GCC-3.x versions I've got
here.
If you don't even *report* the bug, how can you expect it to get fixed?
> They didn't always fail on literal string
> concatenation (IIRC some short ones compiled
> ok), but they consistently failed to concatenate
> literal strings correctly for some source
> files that gcc-2.95.3 would compile correctly
> every time.
The preprocessor was totally rewritten between GCC-2.95.x and GCC-3.x: a
number of things that were valid in 2.95.x but invalid under ISO C were
made to not work in 3.x (for example, the compiler warns about attempts
to concatenate two things with ## that aren't preprocessing tokens, and
eventually this was made a hard error, IIRC).
This is, of course, not a bug.
I can find no mention of string concatenation bugs against the new
preprocessor relating to anything other than token pasting (and all of
those bugs are people trying to token-paste things that aren't tokens,
generally strings).
> (The glibc trees had distributor patches, so I filed
> the bug report via their support
What? You found a compiler bug, so you reported it as a bug against
glibc?
> In sum: for production code it doesn't matter
> what all a new C compiler version can do that
> the old one could not if it won't compile
> quite ordinary standard C correctly.
... especially if the people who see the problems don't report them and
don't provide reproducible testcases.
> It would be good to have bugs fixed in the new compilers,
It would be good if people would report bugs in the new compilers. :)
> because they
> obviously have some advantages (I noticed that gcc-3.4.x seemed quite
> a bit faster than 2.95.3 when compiling glibc,
It is quite a bit slower :(
--
`Preliminary analysis reveal there are few impact craters on Titan. This
suggests Cassini has an active surface constantly being resurfaced.'
--- BBC News Online introduces a new planetary body
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
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 ;)
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.
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? :)
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
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
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
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
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 -- [email protected]
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
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
> 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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
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
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.
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
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 <[email protected]>
--- 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
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
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
On Sat, 6 Nov 2004 00:02:22 +0100 (CET), Grzegorz Kulewski
<[email protected]> 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
> 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.
> 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 <[email protected]>
--- 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
On Fri, 5 Nov 2004, DaMouse wrote:
> On Sat, 6 Nov 2004 00:02:22 +0100 (CET), Grzegorz Kulewski
> <[email protected]> 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
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 <[email protected]>
--- 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
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
>You found a compiler bug, so you reported
>it as a bug against
>glibc?
You don't think it's possible that a glibc bug
could cause unexpected behavior in a gcc that is
using the glibc libraries?
I assure you it is. gcc-2.95.3 failed compiling
file.c from strace-4.4.1 when running with glibc-2.3.2
as it's libc, while it compiles it just fine when
running with glibc-2.2.5 as it's libc. (I included
this information and the compile log in my bug
report to the linux distributor.)
I don't know whether glibc-2.3.2 *really*
had the bug or whether gcc-2.95.3 had some
dodgy workaround for a bug in earlier glibc2
versions that fixing a bug in glibc-2.3.2
then exposed. Or if any of the glibc vendor
patches were involved (something that should
probably be sorted out before deciding to
file the bug report to gcc-bug@, so as not
to unnecessarily waste the time of gcc
maintainers).
Anyway, that's kind of beside the point.
It was merely an example of how a user
might come to decline an "obvious" gcc upgrade.
I guess what I was trying to say is that users
compiling the kernel with older gcc versions is
less a function of user perversity in refusing to
modernize their tools than it is a result of focus.
What problem is the user trying to solve while
using linux? Solving problems usually requires
eliminating variables that may present obstacles
to arriving at a solution, whether that solution
is working production code, some statistical result,
a document that displays correctly, correctly routed
network flows, whatever.
So users arrive at a relatively stable compiler,
they stop upgrading and use that. They find a
kernel that stays up for a week with no oops
reports or other wierdness, they use that. They
will periodically upgrade the compiler, libc,
kernel, etc, when they have a little spare time,
to take advantage of security fixes, new features,
better performance, whatever, *as long as the upgrade
does not become another variable in the problem that
the user is trying to solve*.
If it does turn out to be a variable (unstable
or in some other way unreliable), they toss it
and go back to the old version, because eliminating
variables until they arrive at the solution to their
problem is what they do. Any other method ends up
in combinatorial hell, and they never find a solution
to their problem except by luck.
Many are quite willing to test new versions, report
bugs, send in patches, etc, just to contribute, but
if their main focus is on other problems, they go back
to the last stable version right away for their
everyday work.
This is not perverse, selfish, or uncooperative
behavior, it's merely normal problem-solving
methodology. On what basis would one expect
anything else from such a large user base?
--
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm
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
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.
I can't offer that, but at least some more historic data on kernels
for my machines:
[~:42349] ls -ltr /boot|grep linu
... 231940 Mar 15 1994 vmlinux #1.0
... 219652 Jul 19 1994 vmlinux_ethernet #1.0
... 265188 Dec 7 1994 vmlinux-1.1.59-net
... 273380 Mar 29 1995 vmlinux-1.2.1
... 273412 Jun 4 1995 vmlinux-1.2.9
... 293892 Oct 26 1995 vmlinux-1.2.9-idecd
... 281604 Dec 9 1995 vmlinux-1.2.13
... 310276 May 9 1996 vmlinux-1.2.13-scsi
... 330756 Oct 30 1996 vmlinux-1.2.13-scsi-sound
... 446281 Dec 8 1997 vmlinuz-2.0.32-rh5.0
... 425237 Dec 20 1997 vmlinuz-2.0.32
... 381607 Jun 24 1998 vmlinuz-2.0.34
... 358407 Jul 3 1998 vmlinuz-2.0.34-2
... 480144 Sep 22 1998 vmlinuz-2.1.122
... 452853 Feb 9 1999 vmlinux-2.2.1
... 617431 May 8 1999 vmlinuz-2.2.5-15
... 721343 Dec 18 1999 vmlinuz-suse
... 500762 Jan 26 2000 vmlinux-2.2.14
... 728255 Nov 28 2000 vmlinux-2.4.0-test11
... 737572 Jun 3 2001 vmlinux-2.4.0-test11-cdrw
... 737575 May 10 2002 vmlinux-2.4.0-test11-usb
... 811903 Sep 26 2002 vmlinux-2.4.19
... 1330830 Nov 27 2003 vmlinux-2.4.21-suse
... 1270508 Nov 29 2003 vmlinuz-2.4.20-bf2.4
... 1322073 Feb 18 2004 vmlinuz-2.4.22-1.2174.nptl
... 1099371 Apr 4 2004 vmlinuz-2.4.25-amd64-nonetfilter
... 1101157 Apr 4 2004 vmlinuz-2.4.25-amd64
... 1062450 Apr 4 2004 vmlinuz-2.4.25-i386
... 1052249 Apr 13 2004 vmlinuz-2.4.25-i386-noagp
... 1068566 Apr 18 2004 vmlinuz-2.4.25-amd64-20040418
... 1017406 Apr 29 2004 vmlinuz-2.4.26-amd64
... 1271027 May 4 2004 vmlinuz-2.6.5-amd64
... 1271488 May 9 20:15 vmlinuz-2.6.5-amd64-20040509
I also still have a number of them in my LILO menu that probably don't
work:-)
- anton
--
M. Anton Ertl Some things have to be seen to be believed
[email protected] Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
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
# > > 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
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
<[email protected]> wrote:
> On Fri, 5 Nov 2004, DaMouse wrote:
>
> > On Sat, 6 Nov 2004 00:02:22 +0100 (CET), Grzegorz Kulewski
> > <[email protected]> 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
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
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
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
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
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)
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
On 6 Nov 2004, Clayton Weaver stated:
>>You found a compiler bug, so you reported
>>it as a bug against
>>glibc?
>
> You don't think it's possible that a glibc bug
> could cause unexpected behavior in a gcc that is
> using the glibc libraries?
Naturally it is; it's even fairly common if you're using a very old
compiler or a very old glibc (although support for libc5 is gone as of
GCC-3.4.)
> I don't know whether glibc-2.3.2 *really*
> had the bug or whether gcc-2.95.3 had some
> dodgy workaround for a bug in earlier glibc2
> versions that fixing a bug in glibc-2.3.2
> then exposed.
That's unlikely.
I just doubt that a bug in string concatenation could be chalked up to
glibc, is all.
> So users arrive at a relatively stable compiler, they stop upgrading
> and use that.
They're of course free to do that, if they don't mind not getting access
to new stuff in the new releases; at least if they're working in C
(anyone compiling C++ code with GCC<3.x is a little strange, in my
opinion).
--
`Random line noise picked up from an RS432 cable hung in front of a faulty
radar transmitter. ' --- Greg Hennessy on sendmail.cf
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.
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
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 ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me