2.5.21: kbuild changes broke filenames with commas
With the latest kbuild version in 2.5.21, we are unable to build the following files:
linux/drivers/block/smart1,2.hlinux/drivers/scsi/53c7,8xx.clinux/drivers/scsi/53c7,8xx.h
linux/drivers/scsi/53c7,8xx.scrlinux/arch/arm/mm/proc-arm6,7.Slinux/arch/arm/mm/proc-arm2,3.S
This is because we end up passing gcc the following argument:
-Wp,-MD,.proc-arm6,7.o.d
which gets passed to cpp0 as:
-MD .proc-arm6 7.o.d ^ space, not comma
and therefore cpp0 sees "-MD", ".proc-arm6" and "7.o.d" as separate arguments.
There seems to be two solutions:
1. renaming all the above files to contain '_' instead of ','.
2. see if kbuild can use the DEPENDENCIES_OUTPUT environment variable
Kai pointed out that we've already got one exception in kbuild to fixup the filename for KBUILD_BASENAME (, -> _ and that's not a weird smilie!) so (1) is probably going to be better, and we can get rid of the special "comma" handling.
Either way, I plan to rename the two ARM files. That leaves the 53c7,8xx driver and that block header file.
Signature · 2 lines
Russell King ([email protected]) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
Upper limits to number of processes / threads in Linux / ia32??
Are there any practical limits in Linux on the ia32 to the number of processes / threads that can be managed at one time? What's the largest number of threads that anyone has seen work?
--
How to Stop A Folksinger Cold # 2
"Are you going to Scarborough Fair?..."
No.
Quoted 9 lines · Russell King
With the latest kbuild version in 2.5.21, we are unable to build the following files:
linux/drivers/block/smart1,2.hlinux/drivers/scsi/53c7,8xx.clinux/drivers/scsi/53c7,8xx.h
linux/drivers/scsi/53c7,8xx.scrlinux/arch/arm/mm/proc-arm6,7.Slinux/arch/arm/mm/proc-arm2,3.S
Well, we're unable to build drivers/scsi/53c7,8xx.c and the two ARM files, the others just get included, so don't affect the build. 53c7,8xxx is broken by BIO changes, so nobody but ARM is affected currently.
Quoted 9 lines
This is because we end up passing gcc the following argument:
-Wp,-MD,.proc-arm6,7.o.dwhich gets passed to cpp0 as:
-MD .proc-arm6 7.o.d ^ space, not comma
Quoted 7 lines
and therefore cpp0 sees "-MD", ".proc-arm6" and "7.o.d" as separate arguments.
There seems to be two solutions:
1. renaming all the above files to contain '_' instead of ','.
2. see if kbuild can use theDEPENDENCIES_OUTPUTenvironment variable
There's three way around the limitation of "-Wp" to pass arguments containing commas to cpp:
o Use the environment variable SUNPRO_DEPENDENCIES instead or
o Invoke cpp directly or
o Rename the generated temporary .d file by substituting ',' with something else.
Quoted 4 lines
Kai pointed out that we've already got one exception in kbuild to fixup the filename for
KBUILD_BASENAME(, -> _ and that's not a weird smilie!) so (1) is probably going to be better, and we can get rid of the special "comma" handling.
It would in general be saner to generally disallow source file names with a ',' in them. Not so much for the build system, but also for the other cases where we can't handle them, like e.g. KBUILD_BASENAME as used in include/linux/spinlock.h, or in Rusty's work, which will allow to pass parameters to built-in modules on the kernel command line, like <module name>.<parm>=<value>.
--Kai
Quoted 3 lines · Russell King
With the latest kbuild version in 2.5.21, we are unable to build the following files:
[snip]
Quoted 3 lines
linux/drivers/scsi/53c7,8xx.clinux/drivers/scsi/53c7,8xx.h
linux/drivers/scsi/53c7,8xx.scr
How about we remove these alltogether? The ncr53c8xx and sym-2 drivers both support the 53c810, 53c825, and 53c820 devices and there's a 'common' 53c7xx backend which handles the 53c700, 53x700-66 53c710 and 53c720 chipsets that the 53c7,8xx driver handles. The only minor issue is that if there's any ISA (PCI?) cards with these chipsets would need a new front-end to detect the cards.
Signature · 2 lines
Tom Rini (TR1265) http://gate.crashing.org/~trini/
Quoted 9 lines · Russell King
With the latest kbuild version in 2.5.21, we are unable to build the following files:
linux/drivers/block/smart1,2.hlinux/drivers/scsi/53c7,8xx.clinux/drivers/scsi/53c7,8xx.h
linux/drivers/scsi/53c7,8xx.scrlinux/arch/arm/mm/proc-arm6,7.Slinux/arch/arm/mm/proc-arm2,3.S
kbuild 2.5 can handle filenames with ',' in the name. I do not believe in restricting what users can do unless there is absolutely no alternative. In this case a smarter build system can handle special filenames.
Quoted 11 lines · Keith Owens
Quoted 6 lines
linux/drivers/block/smart1,2.hlinux/drivers/scsi/53c7,8xx.clinux/drivers/scsi/53c7,8xx.h
linux/drivers/scsi/53c7,8xx.scrlinux/arch/arm/mm/proc-arm6,7.Slinux/arch/arm/mm/proc-arm2,3.Skbuild 2.5 can handle filenames with ',' in the name. I do not believe in restricting what users can do unless there is absolutely no alternative. In this case a smarter build system can handle special filenames.
I've already fixed up the two ARM ones. That leaves one problematic file - 53c7,8xx.c.
Is it really worth adding complexity to a build system to work around what is really a GCC bug for just one file? I don't think so.
Signature · 2 lines
Russell King ([email protected]) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
Hi,
Quoted 2 lines · Russell King
Is it really worth adding complexity to a build system to work around what is really a GCC bug for just one file? I don't think so.
Think big! Think about __future__.
Regards,
Thunder
Signature · 4 lines
German attitude becoming | Thunder from the hill at ngforever
rightaway popular: |
"Get outa my way, | free inhabitant not directly
for I got a mobile phone!" | belonging anywhereQuoted 5 lines · Thunder from the hill
Quoted 2 lines · Russell King
Is it really worth adding complexity to a build system to work around what is really a GCC bug for just one file? I don't think so.
Think big! Think about
__future__.
The path to overdesign and excessive featurebloat.
Signature · 2 lines
Russell King ([email protected]) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
Hi
Quoted 4 lines · On Tue 11 Jun 2002 Russell King wrote:
Quoted 1 line · On Tue Jun 11 2002 at 05:11:13AM -0600 Thunder from the hill wrote:
Think big! Think about
__future__.The path to overdesign and excessive featurebloat.
Well the question is then how will things look without commas? I suppose if we have very complex things and prevent using commas whereas I don't assert that we do for text but this is just a bloat example it's good to have things like commas allowed even though we are in case we won't allow them there talking about file names.
If we allow commas all over the filesystem and likewise say that there is nothing to mention about it why should we refuse them for kbuild especially since there is a parallel system which allows commas?
Regards
Thunder
Signature · 4 lines
German attitude becoming | Thunder from the hill at ngforever
rightaway popular: |
"Get outa my way | free inhabitant not directly
for I got a mobile phone!" | belonging anywhereQuoted 9 lines · Thunder from the hill
Well the question is then how will things look without commas? I suppose if we have very complex things and prevent using commas whereas I don't assert that we do for text but this is just a bloat example it's good to have things like commas allowed even though we are in case we won't allow them there talking about file names.
If we allow commas all over the filesystem and likewise say that there is nothing to mention about it why should we refuse them for kbuild especially since there is a parallel system which allows commas?
You've *completely* missed the point.
The gcc argument >>> -Wp,-MD,foo,bar.c <<< is the problem. If anything should be fixed, its that silly gcc syntax. kbuild should not work around the inability of gcc to accept filenames with commas in.
Signature · 2 lines
Russell King ([email protected]) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
Quoted 3 lines · Thunder from the hill
If we allow commas all over the filesystem and likewise say that there is nothing to mention about it why should we refuse them for kbuild especially since there is a parallel system which allows commas?
Aehm, if you argument with what we allow in the filesystem, then I could argue, that everything except '\0' and '/' is allowed to build paths.
Interesting is what the C-Standard says about naming conventions for files.
The rest is merely taste and limitations of the build system.
I like ',' as much as ' ' and quotes in file names. But sh*t happens and we usally have to cope with it :-/
Regards
Ingo Oeser
Signature · 1 line
Science is what we can tell a computer. Art is everything else. --- D.E.Knuth
Hi,
Quoted 6 lines · Ingo Oeser
Quoted 3 lines · Thunder from the hill
If we allow commas all over the filesystem and likewise say that there is nothing to mention about it why should we refuse them for kbuild especially since there is a parallel system which allows commas?
Aehm, if you argument with what we allow in the filesystem
I just said that there seems a way to do it.
Regards,
Thunder
Signature · 4 lines
German attitude becoming | Thunder from the hill at ngforever
rightaway popular: |
"Get outa my way, | free inhabitant not directly
for I got a mobile phone!" | belonging anywhereHi,
Quoted 3 lines · Russell King
Quoted 1 line
Think big! Think about
__future__.The path to overdesign and excessive featurebloat.
Hmmm... You can overdo both sides. OTOH, why do we need IrDA drivers? Featurebloat? Or new processor impls? They're certainly features, required to run the kernel under certain (very limited) conditions. I don't think you would remove them!
Regards,
Thunder
Signature · 4 lines
German attitude becoming | Thunder from the hill at ngforever
rightaway popular: |
"Get outa my way, | free inhabitant not directly
for I got a mobile phone!" | belonging anywhereQuoted 13 lines · Russell King
Quoted 11 lines · Keith Owens
Quoted 6 lines
linux/drivers/block/smart1,2.hlinux/drivers/scsi/53c7,8xx.clinux/drivers/scsi/53c7,8xx.h
linux/drivers/scsi/53c7,8xx.scrlinux/arch/arm/mm/proc-arm6,7.Slinux/arch/arm/mm/proc-arm2,3.Skbuild 2.5 can handle filenames with ',' in the name. I do not believe in restricting what users can do unless there is absolutely no alternative. In this case a smarter build system can handle special filenames.
Quoted 5 lines
I've already fixed up the two ARM ones. That leaves one problematic file - 53c7,8xx.c.
Is it really worth adding complexity to a build system to work around what is really a GCC bug for just one file? I don't think so.
Are you sure that complexity was added just to handle commas in names? Or is it really an example of how good design never gave this bug a chance to exist in the first palce.
I *really* don't like the idea of papering over such bugs by curing the symptoms, as you seem to be advocating.
Signature · 1 line
Daniel
Quoted 9 lines · Daniel Phillips
Quoted 2 lines
Is it really worth adding complexity to a build system to work around what is really a GCC bug for just one file? I don't think so.
Are you sure that complexity was added just to handle commas in names? Or is it really an example of how good design never gave this bug a chance to exist in the first palce.
I *really* don't like the idea of papering over such bugs by curing the symptoms, as you seem to be advocating.
AFAICS you are advocating exactly that - papering over the idiotic gcc options syntax by kludges in build system...
Quoted 9 lines · Alexander Viro
Quoted 7 lines · Daniel Phillips
Quoted 2 lines
Is it really worth adding complexity to a build system to work around what is really a GCC bug for just one file? I don't think so.
Are you sure that complexity was added just to handle commas in names? Or is it really an example of how good design never gave this bug a chance to exist in the first palce.
Quoted 5 lines
Quoted 2 lines
I *really* don't like the idea of papering over such bugs by curing the symptoms, as you seem to be advocating.
AFAICS you are advocating exactly that - papering over the idiotic gcc options syntax by kludges in build system...
So you want to leave this hole sitting there waiting for someone else to step in it, until gcc gets fixed? I'd think a bug report would be a more effective solution than holding one's breath until blue in the face.
I don't have a problem with fixing this at the interface to gcc level, as then it's fixed definitively for the whole kbuild system. I do have a problem with just changing the names of files that trigger the bug, that's sloppy beyond the belief and it's the stuff that substandard systems are made of.
Signature · 1 line
Daniel
Quoted 6 lines · Daniel Phillips
Are you sure that complexity was added just to handle commas in names? Or is it really an example of how good design never gave this bug a chance to exist in the first palce.
I *really* don't like the idea of papering over such bugs by curing the symptoms, as you seem to be advocating.
Lets see.
We have two places in 2.5.21 where commas are unacceptable:
1. -DKBUILD_BASENAME=$(subst $(comma),_,$(subst -,_,$(*F)))
We need to do this because to do because KBUILD_BASENAME is used in places where commas are not acceptable.
We papered over the fact that make can't subst commas by using the $(comma) construct.
2. -Wp,-MD,.$(subst /,_,$@).d (currently unfixed)
This would need to become something like:
-Wp,-MD,.$(subst /,_,$(subst $(comma,_,$@)).d
So now we have two places where the same yucky substing of commas to something more palettable happens. Now, what if we had:
foo,bar.c
and
foo_bar.c
in the same directory? The kbuild system goes wrong, destroying dependency information, using the wrong KBUILD_BASENAME. Oops. I guess we papered over a bug by allowing commas in filenames.
In addition, I'd like to point out the following paragraph in the make info files:
The variant variables' names are formed by
appending D' or F', respectively. These variants are semi-obsolete in GNU make' since the functions dir' and `notdir' can be used to get a similar effect (*note Functions for File Names: File Name Functions.).
Both kbuild-2.5 and the existing kernel build make heavy use of the "$(*F)" notation. Should we really be putting semi-obsolete features into either of the kernel build system?
Signature · 2 lines
Russell King ([email protected]) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
Quoted 31 lines · Russell King
Quoted 6 lines · Daniel Phillips
Are you sure that complexity was added just to handle commas in names? Or is it really an example of how good design never gave this bug a chance to exist in the first palce.
I *really* don't like the idea of papering over such bugs by curing the symptoms, as you seem to be advocating.
Lets see.
We have two places in 2.5.21 where commas are unacceptable:
1. -DKBUILD_BASENAME=$(subst $(comma),_,$(subst -,_,$(*F)))
We need to do this because to do because
KBUILD_BASENAMEis used in places where commas are not acceptable.We papered over the fact that make can't subst commas by using the $(comma) construct.
2. -Wp,-MD,.$(subst /,_,$@).d (currently unfixed)
This would need to become something like:
-Wp,-MD,.$(subst /,_,$(subst $(comma,_,$@)).dSo now we have two places where the same yucky substing of commas to something more palettable happens. Now, what if we had:
foo,bar.c
Quoted 7 lines
and
foo_bar.cin the same directory? The kbuild system goes wrong, destroying dependency information, using the wrong
KBUILD_BASENAME. Oops. I guess we papered over a bug by allowing commas in filenames.
Yup.
Quoted 9 lines
In addition, I'd like to point out the following paragraph in the make info files:
The variant variables' names are formed by
appendingD' orF', respectively. These variants are semi-obsolete in GNUmake' since the functionsdir' and `notdir' can be used to get a similar effect (*note Functions for File Names: File Name Functions.).
Quoted 3 lines
Both kbuild-2.5 and the existing kernel build make heavy use of the "$(*F)" notation. Should we really be putting semi-obsolete features into either of the kernel build system?
No, agreed. Now this is sensible.
Signature · 1 line
Daniel