Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Hi! > > (2) Make the architecture a configuration variable (!) > > Why? > > You still need to have all the damn cross-compilers etc. At which point > being a configuration variable is the _least_ of your worries. You're > better off with just a new tree. Crosscompilers are easy: take pre-compiled cross-compiler, unpack it to /usr/mipsel-linux and you are done. But inability to share sources between i386 and mips/r39xx is a problem for me: each tree is 100MB in size. [Not easily solved as mips/r39xx uses cvs etc...] > > (3) A collection of RPM's so that people can download and install > > all the cross tools easily. > > Hey, maybe you have a few 18GB disks lying around, but none of the > machines I use every day could afford to have another 5-6 cross- > compilation environments lying around. It's just not practical. What? Cross compilation environment for mips is ... just under 40MB. That's three times smaller than my linux tree: root@bug:~# ls -al /usr/mipsel-linux lrwxrwxrwx 1 root root 31 May 29 16:02 /usr/mipsel-linux -> /usr/src/velo/usr/mipsel-linux// root@bug:~# du -s /usr/src/velo/usr/mipsel-linux/ 38388 /usr/src/velo/usr/mipsel-linux root@bug:~# du -s /usr/src/linux 139280 /usr/src/linux root@bug:~# Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Hi! (2) Make the architecture a configuration variable (!) Why? You still need to have all the damn cross-compilers etc. At which point being a configuration variable is the _least_ of your worries. You're better off with just a new tree. Crosscompilers are easy: take pre-compiled cross-compiler, unpack it to /usr/mipsel-linux and you are done. But inability to share sources between i386 and mips/r39xx is a problem for me: each tree is 100MB in size. [Not easily solved as mips/r39xx uses cvs etc...] (3) A collection of RPM's so that people can download and install all the cross tools easily. Hey, maybe you have a few 18GB disks lying around, but none of the machines I use every day could afford to have another 5-6 cross- compilation environments lying around. It's just not practical. What? Cross compilation environment for mips is ... just under 40MB. That's three times smaller than my linux tree: root@bug:~# ls -al /usr/mipsel-linux lrwxrwxrwx 1 root root 31 May 29 16:02 /usr/mipsel-linux - /usr/src/velo/usr/mipsel-linux// root@bug:~# du -s /usr/src/velo/usr/mipsel-linux/ 38388 /usr/src/velo/usr/mipsel-linux root@bug:~# du -s /usr/src/linux 139280 /usr/src/linux root@bug:~# Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Martin Dalecki <[EMAIL PROTECTED]> writes: > There is some facility allowing to implement this kind of things > in the C++ part of the most recent EGCS version which makes implementing > such things "relatively" easy - basiclly there is the provision to dump > the parser trees as easy to process ascii text already there. > > Basically I think this dererr of syntactical analysis can only be > implementen by serious help from the compiler. Luckily, as you said, GCC can do it :) g++ only, for now, but this should change. > Maybe this is a new argument to facilitate at least correct syntactical > processing of the kernel by the C++ flavour of EGCS? No. By the time GCC 3.0 comes out, function-at-a-time processing will have migrated to C as well; the process is already underway. > Please note that this wouldn't need to generate really executable code - > which as we all know is rather difficult due to the extensive runtime > support as well as ehm. the wired calling conventions C++ is oppressing > on the compiler... Just correct syntactical processing is all what's > neccessary - But it isn't needed; GCC 3.0 should support this sort of thing in C, too, unless there is something I am missing. -- `OS's and GUI's come and go, only Emacs has lasting power.' --- Per Abrahamsen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Thu, 7 Sep 2000 19:14:26 -0500, Michael Elizabeth Chastain <[EMAIL PROTECTED]> wrote: >> Yeah. Long transition, plus user education (which never works, dontcha >> know), plus probably a helper tool akin to checkconfig. > >I think it would help to have a well documented "module writers kit". >(Maybe there is one and I'm not aware of it). http://www.linuxdoc.org/LDP/lkmpg/mpg.html, by Ori Pomerantz. He does not have time to maintain it any more so I have volunteered to take it over. Now I just have to find some free time to update it, maybe after the ski season in Oz has finished. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
> Yeah. Long transition, plus user education (which never works, dontcha > know), plus probably a helper tool akin to checkconfig. I think it would help to have a well documented "module writers kit". (Maybe there is one and I'm not aware of it). mec> I'm all in favor of 'if ( CONFIG_BAR )', but I think it will have to mec> be 'if ( CONFIG_BAR - 0 )' if you want to use them any time soon. peter> Am I being obtuse? What is the functional difference? Doh, I am thinking in the wrong language again! "CONFIG_BAR - 0" works when $CONFIG_BAR might expand to either "" or "1". But that's not what happens in 2.4.0 and it's not what happens under Al Viro's proposal. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
[mec] > In the .config file, the problem is that the Makefiles source .config > and then do a lot of "ifdef CONFIG_FOO" tests. There are about 300 > instances of this in 2.4.0-test-7. Separate issue. We're not talking about emitting n symbols to .config, or at least I'm not. In this thread. > In include/linux/autoconf.h, the problem is in the *.c (and *.h and *.S) > files that do a lot of "#ifdef CONFIG_BAR" and "#if defined(CONFIG_BLETCH) > tests. There are about 8000 instances of this in 2.4.0-test-7. I didn't say it would be a *short* transition. I said the above would all have to become "#if CONFIG_BAR" which is perfectly legal (an undefined value compares as 0, and Configure #defines things to 1). > Even worse, any third-party module source is likely to contain the same > "#ifdef CONFIG_BAR" tests. Changing the definitions of CONFIG_BAR will > silently break all of them. Yeah. Long transition, plus user education (which never works, dontcha know), plus probably a helper tool akin to checkconfig. > I'm all in favor of 'if ( CONFIG_BAR )', but I think it will have to > be 'if ( CONFIG_BAR - 0 )' if you want to use them any time soon. Am I being obtuse? What is the functional difference? I think you would get a "CONFIG_BAR undeclared (first use this function)" either way, right? Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
In the .config file, the problem is that the Makefiles source .config and then do a lot of "ifdef CONFIG_FOO" tests. There are about 300 instances of this in 2.4.0-test-7. In include/linux/autoconf.h, the problem is in the *.c (and *.h and *.S) files that do a lot of "#ifdef CONFIG_BAR" and "#if defined(CONFIG_BLETCH) tests. There are about 8000 instances of this in 2.4.0-test-7. Even worse, any third-party module source is likely to contain the same "#ifdef CONFIG_BAR" tests. Changing the definitions of CONFIG_BAR will silently break all of them. I'm all in favor of 'if ( CONFIG_BAR )', but I think it will have to be 'if ( CONFIG_BAR - 0 )' if you want to use them any time soon. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
If you want to look at an existing source-code analyzer that works hand-in-glove with compilers, to skim for good or bad ideas, take a look at the LSE/SCA combo from the DECset tools. (Dunno if DECset is even still available; I lost track of what went where as they were dicing up the company.) -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] 2000-05-05 13:27:15 GMT -- still no icebergs in the White River - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
David Woodhouse wrote: > But how much work would it require to do so? If your theoretical vendor of > closed-source compiler backends were to believe that a shared lib of the > GCC frontend would be legal, surely they'd just make it shared themselves, > then use it as such? It's hardly a effective preventative measure. Yes, there is nothing to prevent a vendor doing that _if_ they take care to ensure their proprietary code doesn't include inline functions / large macros etc. from the GCC header files. A clean interface to the shared library, where the interface is written by that vendor would do it. The interface code would have to be released under a GPL compatible license, that also permits the vendor to make use of it. E.g. LGPL would do for the interface header files, as would many other licenses. Such a thing won't be accepted into the main GCC distribution though. It's probably easier to use a pipe anyway. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
[viro] > The _real_ problem is preprocessor abuse. BTW, could we schedule for > 2.5 the following? > * things like CONFIG_FOO are _always_ defined. As 0 or 1, that is. > * #ifdef CONFIG_FOO => if (CONFIG_FOO) in *.c. gcc will kill the unused > branches just fine. Notwithstanding the string literal gcc bug already mentioned It's non-trivial at the kernel config stage. As in, a rewrite of config and menuconfig (might be easier for xconfig). Because currently they leverage bash parsing and control flow, so parts of Config.in files are not seen by Configure/Menuconfig proper. So some of the #define CONFIG_X 0 can't happen, with current design. It's really the same problem you're complaining about, all over again. bash acts as the preprocessor here. Not that most of us particularly like the bash-parsing implementations currently in use, but there they are. If and when esr's new config stuff is adopted this sort of thing will be *much* easier to add cleanly. Actually, hackery would be possible -- have a stage of `make config' that basically greps all Config.in files for words CONFIG_* and makes sure they are all #defined, one way or another. Hackery is hackery, though there's already a lot of it in the kbuild system. Migration strategy: 1. s/#ifdef/#if/ all over the kernel (for CONFIG_* only of course -- other macros aren't guaranteed to evaluate to true). 2. Play with kbuild until you get the 1's and 0's. 3. Start putting the real C control flow in. I will do the step 2 hackery, if you want. (As I said it won't be pretty.) > * Yes, Virginia, it means that controlflow-affecting expansion has to > go. Good riddance, IMO. IMO too. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
[viro] > > making the internal API frozen by exposure to library users. [Gooch] > An exercise in decent API design. BFD. ^^^ Nah, that's the *de*compilation library. (Sorry, couldn't resist.) Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
[EMAIL PROTECTED] said: > Shared library linkage brings you into the same grey area that binary > only kernel modules fall into, this means it's risky and this is > almost certainly how the GCC team views this situation. But how much work would it require to do so? If your theoretical vendor of closed-source compiler backends were to believe that a shared lib of the GCC frontend would be legal, surely they'd just make it shared themselves, then use it as such? It's hardly a effective preventative measure. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Michael Elizabeth Chastain <[EMAIL PROTECTED]> wrote: > We could use some more infrastructure here. > (1) A 'make randomconfig' tool that generates a random configuration. mconfig -m random, it's even written by you ;) my current mconfig working version is on ftp.openlinux.org/pub/people/hch/mconfig Christoph -- Always remember that you are unique. Just like everyone else. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Michael Elizabeth Chastain wrote: > (c) With separate source and build trees, which I've implemented, > it becomes a lot more feaasible to manage kernel builds for > multiple platforms. Is this released? I build most of my kernels for both x86 and PowerPC, plus I build several configurations for diskless clients from the same source tree. > Linus writes ... > > Hey, maybe you have a few 18GB disks lying around, but none of the > > machines I use every day could afford to have another 5-6 cross- > > compilation environments lying around. It's just not practical. About 30MB for a cross-compilation environment capable of building kernels. Then add whatever libraries you need if you want to build userspace, and another 5 or so MB for C++. It's less than a built kernel tree. - Adrian Cox, AG Electronics - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Michael Elizabeth Chastain [EMAIL PROTECTED] wrote: We could use some more infrastructure here. (1) A 'make randomconfig' tool that generates a random configuration. mconfig -m random, it's even written by you ;) my current mconfig working version is on ftp.openlinux.org/pub/people/hch/mconfig Christoph -- Always remember that you are unique. Just like everyone else. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
[viro] making the internal API frozen by exposure to library users. [Gooch] An exercise in decent API design. BFD. ^^^ Nah, that's the *de*compilation library. (Sorry, couldn't resist.) Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
[viro] The _real_ problem is preprocessor abuse. BTW, could we schedule for 2.5 the following? * things like CONFIG_FOO are _always_ defined. As 0 or 1, that is. * #ifdef CONFIG_FOO = if (CONFIG_FOO) in *.c. gcc will kill the unused branches just fine. Notwithstanding the string literal gcc bug already mentioned It's non-trivial at the kernel config stage. As in, a rewrite of config and menuconfig (might be easier for xconfig). Because currently they leverage bash parsing and control flow, so parts of Config.in files are not seen by Configure/Menuconfig proper. So some of the #define CONFIG_X 0 can't happen, with current design. It's really the same problem you're complaining about, all over again. bash acts as the preprocessor here. Not that most of us particularly like the bash-parsing implementations currently in use, but there they are. If and when esr's new config stuff is adopted this sort of thing will be *much* easier to add cleanly. Actually, hackery would be possible -- have a stage of `make config' that basically greps all Config.in files for words CONFIG_* and makes sure they are all #defined, one way or another. Hackery is hackery, though there's already a lot of it in the kbuild system. Migration strategy: 1. s/#ifdef/#if/ all over the kernel (for CONFIG_* only of course -- other macros aren't guaranteed to evaluate to true). 2. Play with kbuild until you get the 1's and 0's. 3. Start putting the real C control flow in. I will do the step 2 hackery, if you want. (As I said it won't be pretty.) * Yes, Virginia, it means that controlflow-affecting expansion has to go. Good riddance, IMO. IMO too. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
If you want to look at an existing source-code analyzer that works hand-in-glove with compilers, to skim for good or bad ideas, take a look at the LSE/SCA combo from the DECset tools. (Dunno if DECset is even still available; I lost track of what went where as they were dicing up the company.) -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] 2000-05-05 13:27:15 GMT -- still no icebergs in the White River - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
In the .config file, the problem is that the Makefiles source .config and then do a lot of "ifdef CONFIG_FOO" tests. There are about 300 instances of this in 2.4.0-test-7. In include/linux/autoconf.h, the problem is in the *.c (and *.h and *.S) files that do a lot of "#ifdef CONFIG_BAR" and "#if defined(CONFIG_BLETCH) tests. There are about 8000 instances of this in 2.4.0-test-7. Even worse, any third-party module source is likely to contain the same "#ifdef CONFIG_BAR" tests. Changing the definitions of CONFIG_BAR will silently break all of them. I'm all in favor of 'if ( CONFIG_BAR )', but I think it will have to be 'if ( CONFIG_BAR - 0 )' if you want to use them any time soon. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Yeah. Long transition, plus user education (which never works, dontcha know), plus probably a helper tool akin to checkconfig. I think it would help to have a well documented "module writers kit". (Maybe there is one and I'm not aware of it). mec I'm all in favor of 'if ( CONFIG_BAR )', but I think it will have to mec be 'if ( CONFIG_BAR - 0 )' if you want to use them any time soon. peter Am I being obtuse? What is the functional difference? Doh, I am thinking in the wrong language again! "CONFIG_BAR - 0" works when $CONFIG_BAR might expand to either "" or "1". But that's not what happens in 2.4.0 and it's not what happens under Al Viro's proposal. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Thu, 7 Sep 2000 19:14:26 -0500, Michael Elizabeth Chastain [EMAIL PROTECTED] wrote: Yeah. Long transition, plus user education (which never works, dontcha know), plus probably a helper tool akin to checkconfig. I think it would help to have a well documented "module writers kit". (Maybe there is one and I'm not aware of it). http://www.linuxdoc.org/LDP/lkmpg/mpg.html, by Ori Pomerantz. He does not have time to maintain it any more so I have volunteered to take it over. Now I just have to find some free time to update it, maybe after the ski season in Oz has finished. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
David Woodhouse wrote: But how much work would it require to do so? If your theoretical vendor of closed-source compiler backends were to believe that a shared lib of the GCC frontend would be legal, surely they'd just make it shared themselves, then use it as such? It's hardly a effective preventative measure. Yes, there is nothing to prevent a vendor doing that _if_ they take care to ensure their proprietary code doesn't include inline functions / large macros etc. from the GCC header files. A clean interface to the shared library, where the interface is written by that vendor would do it. The interface code would have to be released under a GPL compatible license, that also permits the vendor to make use of it. E.g. LGPL would do for the interface header files, as would many other licenses. Such a thing won't be accepted into the main GCC distribution though. It's probably easier to use a pipe anyway. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Date: Wed, 6 Sep 2000 14:42:17 -0700 (PDT) From: Jonathan Walther <[EMAIL PROTECTED]> If the shared library is under GPL (not LGPL) that isn't a problem. No? Shared library linkage brings you into the same grey area that binary only kernel modules fall into, this means it's risky and this is almost certainly how the GCC team views this situation. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Date:Wed, 6 Sep 2000 08:59:56 -0600 From: Richard Gooch <[EMAIL PROTECTED]> Jamie Lokier writes: > Sorry, there's a GCC policy decision against putting it into a > shared library. Why? Because this allows proprietary software vendor X to write closed-source compiler backend Y using GCC to provide the front end. If it never becomes a shared library, this sort of thing cannot happen. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Alexander Viro wrote: > > On Wed, 6 Sep 2000, Martin Dalecki wrote: > > > > > So may I just suggest to repleace the usage of cpp at all with something > > more > > suitable for the task at hand and with a much more regular/stringent > > syntax > > better fitting into the syntax of the pure C language like m4 for > > example? > > > > No. Still "better tools" variant. Check blk_dev_init() and tell me how do > you like the end of this function (drivers/block/ll_rw_blk.c). BTW, check Yes you are right here I don't like this particular piece of code in esp since: 1. The macro hackery may very well be replaced with "vanishing macros" at the declaration level. 2. This is basically an fully unrolled loop of calls into a function pointer table. 3. It's making the corresponding driver code non self contained. > how many of these CONFIG_... are needed anywhere on C level. Hint: see > module_init macro. Yes I like the introduction of the ld hackere there very much: It's basically solving the problems 1. 2. and 3. by doing the proper thing ;-) i.e. provide an statically initialized list of addresses and call them out of a loop. > > The main problem with the CONFIG_ blah's isn't either the syntax nor > > they current usage - the problem is inherent to the simple fact > > that the number of possible combinations is of a very high order due > > to simple combinatorics. > > It's not a fact, it's a problem... It doesn't _have_ to be very high > order on cc level. ld - sure, but that's much simpler to deal with. But in some cases the driver api in linux are not quite supportiv for this. Please have a look at the strattegy routine (please allow me to use the proper UNIX terminology here ;-) declaration hackery inside of ide.h, oh sorry it gote moved and I can't quite find it again... ;-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Alexander Viro wrote: > > Add "and that broken code gets fixed in utterly bogus ways 20 versions > down the road, when nobody remembers WTF had happened". Repeat several > times (and rarely-used parts _will_ accumulate such crap) and you've got > Lovecraftian beasts lurking in the tree. "Lovecraftian beasts". I like it. To some degree that also ends up showing that not many people seem to care about that particular beast. In the end, it might be phased out altogether - something that _has_ happened, exactly for these kinds of reasons. Who still remembers xiafs? We have 33 different filesystems in the kernel tree - something that is quite impressive, and something that I don't think anybody else has ever tried to support. But we could have had 34.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Martin Dalecki wrote: > > So may I just suggest to repleace the usage of cpp at all with something > more > suitable for the task at hand and with a much more regular/stringent > syntax > better fitting into the syntax of the pure C language like m4 for > example? > No. Still "better tools" variant. Check blk_dev_init() and tell me how do you like the end of this function (drivers/block/ll_rw_blk.c). BTW, check how many of these CONFIG_... are needed anywhere on C level. Hint: see module_init macro. > > I think Java has the perfect solution for conditional compilation - > don't > make it possible at al in a sane standard way! Coditional compilation is > evil > like gotos (despite the fact that even every pascal implementation out > there > provided them). > > > The main problem with the CONFIG_ blah's isn't either the syntax nor > they current usage - the problem is inherent to the simple fact > that the number of possible combinations is of a very high order due > to simple combinatorics. It's not a fact, it's a problem... It doesn't _have_ to be very high order on cc level. ld - sure, but that's much simpler to deal with. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Alexander Viro wrote:
>
>
> On 6 Sep 2000, Linus Torvalds wrote:
>
> > However, what I think Al Viro dislikes about this is that it does tend
> > to leave code that won't compile, just because some of the accesses are
> > in places that the compiler doesn't see due to the pre-processor (or due
> > to other build-rules: like in architectures that aren't the one that the
> > developer uses).
>
> Add "and that broken code gets fixed in utterly bogus ways 20 versions
> down the road, when nobody remembers WTF had happened". Repeat several
> times (and rarely-used parts _will_ accumulate such crap) and you've got
> Lovecraftian beasts lurking in the tree. To some extent it's inevitable,
> but frequency of such events matters...
... or they get #if 0'd, as in the case below:
diff -urN rc8-5/arch/mips64/kernel/linux32.c rc8-5-mips/arch/mips64/kernel/linux32.c
--- rc8-5/arch/mips64/kernel/linux32.c Thu Jul 27 21:36:54 2000
+++ rc8-5-mips/arch/mips64/kernel/linux32.c Wed Sep 6 13:59:36 2000
@@ -275,30 +275,33 @@
int do_execve32(char * filename, u32 * argv, u32 * envp, struct pt_regs * regs)
{
struct linux_binprm bprm;
- struct dentry * dentry;
+ struct file *file;
int retval;
int i;
- bprm.p = PAGE_SIZE*MAX_ARG_PAGES-sizeof(void *);
- memset(bprm.page, 0, MAX_ARG_PAGES*sizeof(bprm.page[0]));
+ file = open_exec(filename);
- dentry = open_namei(filename, 0, 0);
- retval = PTR_ERR(dentry);
- if (IS_ERR(dentry))
+ retval = PTR_ERR(file);
+ if (IS_ERR(file))
return retval;
- bprm.dentry = dentry;
+ bprm.p = PAGE_SIZE*MAX_ARG_PAGES-sizeof(void *);
+ memset(bprm.page, 0, MAX_ARG_PAGES*sizeof(bprm.page[0]));
+
+ bprm.file = file;
bprm.filename = filename;
bprm.sh_bang = 0;
bprm.loader = 0;
bprm.exec = 0;
if ((bprm.argc = count32(argv, bprm.p / sizeof(u32))) < 0) {
- dput(dentry);
+ allow_write_access(file);
+ fput(file);
return bprm.argc;
}
if ((bprm.envc = count32(envp, bprm.p / sizeof(u32))) < 0) {
- dput(dentry);
+ allow_write_access(file);
+ fput(file);
return bprm.envc;
}
@@ -326,8 +329,9 @@
out:
/* Something went wrong, return the inode and free the argument pages*/
- if (bprm.dentry)
- dput(bprm.dentry);
+ allow_write_access(bprm.file);
+ if (bprm.file)
+ fput(bprm.file);
/* Assumes that free_page() can take a NULL argument. */
/* I hope this is ok for all architectures */
I suspect that after that patch #if 0 around the whole mess may go to
hell. Ralf?
Notice that in this case code simply was not available in the tree when
changes were done. Right now I've just repeated the grep done back in May
and it brought the instances above. Folks, it didn't compile for 4
months...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Alexander Viro wrote: > > On Wed, 6 Sep 2000, Michael Elizabeth Chastain wrote: > > > We could use some more infrastructure here. > > > > (1) A 'make randomconfig' tool that generates a random configuration. > > > > (2) Make the architecture a configuration variable (!) > > > > (3) A collection of RPM's so that people can download and install > > all the cross tools easily. > > (0) knowledge that CONFIG_FOO15 doesn't affect anything other than set of > source files being compiled. > > Providing better tools is nice, but simplifying the problem domain > sometimes pays better... So may I just suggest to repleace the usage of cpp at all with something more suitable for the task at hand and with a much more regular/stringent syntax better fitting into the syntax of the pure C language like m4 for example? I think Java has the perfect solution for conditional compilation - don't make it possible at al in a sane standard way! Coditional compilation is evil like gotos (despite the fact that even every pascal implementation out there provided them). The main problem with the CONFIG_ blah's isn't either the syntax nor they current usage - the problem is inherent to the simple fact that the number of possible combinations is of a very high order due to simple combinatorics. Hmm maybe the first irony is a quite serious suggestion at least in the case of CONFIG_ options? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Linus writes ... mec> (2) Make the architecture a configuration variable (!) linus> Why? The real reason is that it's the right thing to do. Part of a configuration is "what machine it's for". Here are some benefits: (a) Arjan's testing machinery would catch problems in all architectures, not just the x86. (b> The sparc / sparc64 people can manage their builds a lot easier. (c) With separate source and build trees, which I've implemented, it becomes a lot more feaasible to manage kernel builds for multiple platforms. > Hey, maybe you have a few 18GB disks lying around, but none of the > machines I use every day could afford to have another 5-6 cross- > compilation environments lying around. It's just not practical. So don't do it. You build with your favorite configuration, and I'll build with my favorite 100 configurations. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
r > (0) knowledge that CONFIG.FOO15 doesn't affect anything other than set of > source files being compiled. The Makefiles already know this. Specifically, mkdep.c analyzes which C files depend on which options. Look at some of your .depend files. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On 6 Sep 2000, Linus Torvalds wrote: > However, what I think Al Viro dislikes about this is that it does tend > to leave code that won't compile, just because some of the accesses are > in places that the compiler doesn't see due to the pre-processor (or due > to other build-rules: like in architectures that aren't the one that the > developer uses). Add "and that broken code gets fixed in utterly bogus ways 20 versions down the road, when nobody remembers WTF had happened". Repeat several times (and rarely-used parts _will_ accumulate such crap) and you've got Lovecraftian beasts lurking in the tree. To some extent it's inevitable, but frequency of such events matters... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Michael Elizabeth Chastain wrote: > > We could use some more infrastructure here. > > (1) A 'make randomconfig' tool that generates a random configuration. There already are people that do this. The problem is that developers are lazy. All good programmers are lazy. They want to fix the problem - they don't want to wait for a day or two until all combinations have been tested. They want a "grep"-like thing. Not that it matters much. In the end, non-compiling kernel versions are quite acceptable as they fix bugs and they'll get fixed themselves eventually. So this is not probably that big of an issue in real life. Just a beauty wart. > (2) Make the architecture a configuration variable (!) Why? You still need to have all the damn cross-compilers etc. At which point being a configuration variable is the _least_ of your worries. You're better off with just a new tree. > (3) A collection of RPM's so that people can download and install > all the cross tools easily. Hey, maybe you have a few 18GB disks lying around, but none of the machines I use every day could afford to have another 5-6 cross- compilation environments lying around. It's just not practical. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Michael Elizabeth Chastain wrote: > We could use some more infrastructure here. > > (1) A 'make randomconfig' tool that generates a random configuration. > > (2) Make the architecture a configuration variable (!) > > (3) A collection of RPM's so that people can download and install > all the cross tools easily. (0) knowledge that CONFIG_FOO15 doesn't affect anything other than set of source files being compiled. Providing better tools is nice, but simplifying the problem domain sometimes pays better... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On 6 Sep 2000, Linus Torvalds wrote: > At the same time, there is no question that true #ifdef's have > advantages, even outside the issue of gcc's inability to forget literal > strings. They are often required for data structures in general: C does > not have "conditional data structures". Certain fields just do not > exist when SMP is disabled, for example. And we don't _want_ them to > exist, because they bloat out data structures that we're trying to keep > reasonably small. True. But right now we have a heap of CONFIG_FOO and that heap falls into three parts: 1) stuff that is not used in *.[chS]. At all. CONFIG_EXT2, for one. Makefiles - yes, but that's basically "what we link" kind of influence. 2) stuff that _is_ used, but doesn't really have to be #ifdefs 3) tiny group of options that really have to affect the compile in non-trivial ways. CONFIG_SMP is an obvious example. CONFIG_PROC_FS _may_ be another, simply due to the amount of instances in the current code. Architecture is probably one more (even though we could do nicer here). There may be several other (some networking-related ones may be candidates). IWBNI they would be clearly separated and #2 would shrink (some of these guys should be in #1). > So I disagree with the notion that we should try to avoid using #ifdefs > etc completely. But I agree that in many cases you can _locally_ try to > avoid it, resulting in nicer and more flexible code that also has the > advantage of making sure it can be parsed regardless of what the > configuration is. Oh, we certainly can't completely avoid ifdefs without major braindamage. But there is a difference between several hundreds of options and a dozen that decides what would be seen by parser. And even essential ones are, in many cases, used in uglier ways than they have to. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
We could use some more infrastructure here. (1) A 'make randomconfig' tool that generates a random configuration. (2) Make the architecture a configuration variable (!) (3) A collection of RPM's so that people can download and install all the cross tools easily. With this stuff available, I would spend my idle cycles building random kernels and catching the syntax errors. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
In article <8p5u21$r0$[EMAIL PROTECTED]> you wrote: > However, what I think Al Viro dislikes about this is that it does tend > to leave code that won't compile, just because some of the accesses are > in places that the compiler doesn't see due to the pre-processor (or due > to other build-rules: like in architectures that aren't the one that the > developer uses). That's why there are people that try to built all possible combinations of .config options. Granted, that doesn't happen for non-i386 yet, but that is just a matter of available hardware :) Greetings, Arjan van de Ven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
In article <[EMAIL PROTECTED]>, Jamie Lokier <[EMAIL PROTECTED]> wrote: >Linus Torvalds wrote: >> And I'm saying that if people really want to do this, then use the >> computer to do it for you, having more than just "grep", and making your >> tools aware of it. > >I'd just like to add, for the benefit of onlookers, that this is >quite easy. > >Temporarily change name of `count' in struct page in your private tree; >recompile. Voila! Every occurence of page->count will show as a >compile error, with line number. Yes. This is, in fact, how a lot of these things have been done. Often the name-change isn't even just temporary - it stays, because that way nobody will be able to compile old code that depends on old conventions even by mistake. However, what I think Al Viro dislikes about this is that it does tend to leave code that won't compile, just because some of the accesses are in places that the compiler doesn't see due to the pre-processor (or due to other build-rules: like in architectures that aren't the one that the developer uses). That said, it works. This is also the reason why I want the kernel to use as tight type-checking as C allows: because it again allows people to change things _without_ having to be perfectly aware of every single detail that depends on the old calling sequences, as the compiler will warn if the types are mis-used. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
In article <[EMAIL PROTECTED]>, Andrew Morton <[EMAIL PROTECTED]> wrote: > >But still, doing the conditional compilation at compile-time rather than >preprocessing-time is so *nice* that if you don't have too many literal >strings floating about it may be justifiable. > >In cs89x0.c you reduce the object size by 1.5k by setting DEBUGGING to >literal zero - no #ifdefs in sight. Yes. The i387.c thing uses this too to make for much more readable code (instead of using CONFIG_MATH_EMULATION etc, it uses it's own #defines and variables, and lets the compiler sort it all out). It definitely has many advantages, especially in that it allows real C flow and thus much nicer syntax. And a lot of code becomes much nicer if instead of having #ifdef CONFIG_FOO do_this_thing(); #endif you have an unconditional do_this_thing(); and you just define that to possibly end up being zero code for the cases you don't care about - even if you use the pre-processor for that phase. I basically always prefer that kind of syntax. At the same time, there is no question that true #ifdef's have advantages, even outside the issue of gcc's inability to forget literal strings. They are often required for data structures in general: C does not have "conditional data structures". Certain fields just do not exist when SMP is disabled, for example. And we don't _want_ them to exist, because they bloat out data structures that we're trying to keep reasonably small. So I disagree with the notion that we should try to avoid using #ifdefs etc completely. But I agree that in many cases you can _locally_ try to avoid it, resulting in nicer and more flexible code that also has the advantage of making sure it can be parsed regardless of what the configuration is. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Alexander Viro writes: > > > > On Wed, 6 Sep 2000, Richard Gooch wrote: > > > Jamie Lokier writes: > > > Chris Wedgwood wrote: > > > > I think would be really cool if all this 'magic' in gcc (whatever > > > > part of gcc is irrelevant right now) would be exported into a library > > > > or shared object which editors could then load and use... dynamically > > > > perhaps. > > > > > > Sorry, there's a GCC policy decision against putting it into a > > > shared library. > > > > Why? > > Not-so-wild guess: GPL issues, mixed with serious lack of enthisiasm about ^^ That was my guess. Politics. Ideology. Bah. > making the internal API frozen by exposure to library users. An exercise in decent API design. BFD. > Besides, there is another issue: WTF is wrong with good old pipes? In this context, I agree. It's not as if there's an awful lot of data being thrown around. Compilation costs are likely to dominate over in-core copies. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Richard Gooch wrote: > Jamie Lokier writes: > > Chris Wedgwood wrote: > > > I think would be really cool if all this 'magic' in gcc (whatever > > > part of gcc is irrelevant right now) would be exported into a library > > > or shared object which editors could then load and use... dynamically > > > perhaps. > > > > Sorry, there's a GCC policy decision against putting it into a > > shared library. > > Why? Not-so-wild guess: GPL issues, mixed with serious lack of enthisiasm about making the internal API frozen by exposure to library users. Besides, there is another issue: WTF is wrong with good old pipes? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Alan Cox wrote: > > As readability - it's definitely at least as readable as > > #if[def]. It also provides more consistent syntax. And when you are > > using ifdef to violate scoping - your code is in need of rewrite anyway. > > You still need the #ifdef stuff as well for half of it so I dont see what > it buys you I suspect that it will be way less than half, but there is only one way to check it... I'll try to do it, if it will not give visible benefits - too bad, I'll waste some time checking the wrong assumption... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Jamie Lokier writes: > Chris Wedgwood wrote: > > I think would be really cool if all this 'magic' in gcc (whatever > > part of gcc is irrelevant right now) would be exported into a library > > or shared object which editors could then load and use... dynamically > > perhaps. > > Sorry, there's a GCC policy decision against putting it into a > shared library. Why? Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Chris Wedgwood wrote: > I think would be really cool if all this 'magic' in gcc (whatever > part of gcc is irrelevant right now) would be exported into a library > or shared object which editors could then load and use... dynamically > perhaps. Sorry, there's a GCC policy decision against putting it into a shared library. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Linus Torvalds wrote: > And I'm saying that if people really want to do this, then use the > computer to do it for you, having more than just "grep", and making your > tools aware of it. I'd just like to add, for the benefit of onlookers, that this is quite easy. Temporarily change name of `count' in struct page in your private tree; recompile. Voila! Every occurence of page->count will show as a compile error, with line number. Step through each one and make the change. Use editor macro if preferred. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Chris Wedgwood wrote:
[Gcc not eliminating trivial dead code...
did you compile without optimisation?]
Gcc 2.96 does remove the unreached code in your example,
but it still emits string constants.
int func()
{
if (1)
a = "foo";
else
a = "bar";
}
.LC0:
.string "foo"
.LC1:
.string "bar"
.text
.align 4
.globl func
.typefunc,@function
func:
pushl %ebp
movl%esp, %ebp
movl$.LC0, a
popl%ebp
ret
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
> As readability - it's definitely at least as readable as > #if[def]. It also provides more consistent syntax. And when you are > using ifdef to violate scoping - your code is in need of rewrite anyway. You still need the #ifdef stuff as well for half of it so I dont see what it buys you - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
[EMAIL PROTECTED] (Martin Dalecki) wrote on 06.09.00 in <[EMAIL PROTECTED]>: > Alexander Viro wrote: > > > > On Wed, 6 Sep 2000, Martin Dalecki wrote: > > > > > Easy - the same way you do for cross compilation. Basically just: > > > > > > export CC=g++ --some-magic-long-option-i-dont-remember; make > > > > ... and you still have only a subset of the tree, simply because it is fed > > through cpp before it reaches the parser. And cpp cuts away many pieces. > > Different config options and you've got a different subset. Good luck > > providing the coverage. > > That's not quite the problem - with the exception of the boundary cases > of compleatly broken CONFIG_BLAH combinations... You have the fine > .confg file there you know... Count them n and take the n! for all the > possible config choices. Then you will see that THERE CAN'T be any > better > automatic approach then just what I have described above (ie. going > directly into the compiler) and doing the CONFIG_ handling by hand. > (I mean scripting for the most appriopriate choices...) Rather, then you'll see that that approach is completely unviable because the n! is a fscking unbelievable labre number. MfG Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
[EMAIL PROTECTED] (Martin Dalecki) wrote on 06.09.00 in [EMAIL PROTECTED]: Alexander Viro wrote: On Wed, 6 Sep 2000, Martin Dalecki wrote: Easy - the same way you do for cross compilation. Basically just: export CC=g++ --some-magic-long-option-i-dont-remember; make ... and you still have only a subset of the tree, simply because it is fed through cpp before it reaches the parser. And cpp cuts away many pieces. Different config options and you've got a different subset. Good luck providing the coverage. That's not quite the problem - with the exception of the boundary cases of compleatly broken CONFIG_BLAH combinations... You have the fine .confg file there you know... Count them n and take the n! for all the possible config choices. Then you will see that THERE CAN'T be any better automatic approach then just what I have described above (ie. going directly into the compiler) and doing the CONFIG_ handling by hand. (I mean scripting for the most appriopriate choices...) Rather, then you'll see that that approach is completely unviable because the n! is a fscking unbelievable labre number. MfG Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
As readability - it's definitely at least as readable as #if[def]. It also provides more consistent syntax. And when you are using ifdef to violate scoping - your code is in need of rewrite anyway. You still need the #ifdef stuff as well for half of it so I dont see what it buys you - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Jamie Lokier writes: Chris Wedgwood wrote: I think would be really cool if all this 'magic' in gcc (whatever part of gcc is irrelevant right now) would be exported into a library or shared object which editors could then load and use... dynamically perhaps. Sorry, there's a GCC policy decision against putting it into a shared library. Why? Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Alan Cox wrote: As readability - it's definitely at least as readable as #if[def]. It also provides more consistent syntax. And when you are using ifdef to violate scoping - your code is in need of rewrite anyway. You still need the #ifdef stuff as well for half of it so I dont see what it buys you I suspect that it will be way less than half, but there is only one way to check it... shrug I'll try to do it, if it will not give visible benefits - too bad, I'll waste some time checking the wrong assumption... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Richard Gooch wrote: Jamie Lokier writes: Chris Wedgwood wrote: I think would be really cool if all this 'magic' in gcc (whatever part of gcc is irrelevant right now) would be exported into a library or shared object which editors could then load and use... dynamically perhaps. Sorry, there's a GCC policy decision against putting it into a shared library. Why? Not-so-wild guess: GPL issues, mixed with serious lack of enthisiasm about making the internal API frozen by exposure to library users. Besides, there is another issue: WTF is wrong with good old pipes? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Alexander Viro writes: On Wed, 6 Sep 2000, Richard Gooch wrote: Jamie Lokier writes: Chris Wedgwood wrote: I think would be really cool if all this 'magic' in gcc (whatever part of gcc is irrelevant right now) would be exported into a library or shared object which editors could then load and use... dynamically perhaps. Sorry, there's a GCC policy decision against putting it into a shared library. Why? Not-so-wild guess: GPL issues, mixed with serious lack of enthisiasm about ^^ That was my guess. Politics. Ideology. Bah. making the internal API frozen by exposure to library users. An exercise in decent API design. BFD. Besides, there is another issue: WTF is wrong with good old pipes? In this context, I agree. It's not as if there's an awful lot of data being thrown around. Compilation costs are likely to dominate over in-core copies. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
In article [EMAIL PROTECTED], Jamie Lokier [EMAIL PROTECTED] wrote: Linus Torvalds wrote: And I'm saying that if people really want to do this, then use the computer to do it for you, having more than just "grep", and making your tools aware of it. I'd just like to add, for the benefit of onlookers, that this is quite easy. Temporarily change name of `count' in struct page in your private tree; recompile. Voila! Every occurence of page-count will show as a compile error, with line number. Yes. This is, in fact, how a lot of these things have been done. Often the name-change isn't even just temporary - it stays, because that way nobody will be able to compile old code that depends on old conventions even by mistake. However, what I think Al Viro dislikes about this is that it does tend to leave code that won't compile, just because some of the accesses are in places that the compiler doesn't see due to the pre-processor (or due to other build-rules: like in architectures that aren't the one that the developer uses). That said, it works. This is also the reason why I want the kernel to use as tight type-checking as C allows: because it again allows people to change things _without_ having to be perfectly aware of every single detail that depends on the old calling sequences, as the compiler will warn if the types are mis-used. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
In article 8p5u21$r0$[EMAIL PROTECTED] you wrote: However, what I think Al Viro dislikes about this is that it does tend to leave code that won't compile, just because some of the accesses are in places that the compiler doesn't see due to the pre-processor (or due to other build-rules: like in architectures that aren't the one that the developer uses). That's why there are people that try to built all possible combinations of .config options. Granted, that doesn't happen for non-i386 yet, but that is just a matter of available hardware :) Greetings, Arjan van de Ven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
We could use some more infrastructure here. (1) A 'make randomconfig' tool that generates a random configuration. (2) Make the architecture a configuration variable (!) (3) A collection of RPM's so that people can download and install all the cross tools easily. With this stuff available, I would spend my idle cycles building random kernels and catching the syntax errors. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On 6 Sep 2000, Linus Torvalds wrote: At the same time, there is no question that true #ifdef's have advantages, even outside the issue of gcc's inability to forget literal strings. They are often required for data structures in general: C does not have "conditional data structures". Certain fields just do not exist when SMP is disabled, for example. And we don't _want_ them to exist, because they bloat out data structures that we're trying to keep reasonably small. True. But right now we have a heap of CONFIG_FOO and that heap falls into three parts: 1) stuff that is not used in *.[chS]. At all. CONFIG_EXT2, for one. Makefiles - yes, but that's basically "what we link" kind of influence. 2) stuff that _is_ used, but doesn't really have to be #ifdefs 3) tiny group of options that really have to affect the compile in non-trivial ways. CONFIG_SMP is an obvious example. CONFIG_PROC_FS _may_ be another, simply due to the amount of instances in the current code. Architecture is probably one more (even though we could do nicer here). There may be several other (some networking-related ones may be candidates). IWBNI they would be clearly separated and #2 would shrink (some of these guys should be in #1). So I disagree with the notion that we should try to avoid using #ifdefs etc completely. But I agree that in many cases you can _locally_ try to avoid it, resulting in nicer and more flexible code that also has the advantage of making sure it can be parsed regardless of what the configuration is. Oh, we certainly can't completely avoid ifdefs without major braindamage. But there is a difference between several hundreds of options and a dozen that decides what would be seen by parser. And even essential ones are, in many cases, used in uglier ways than they have to. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Michael Elizabeth Chastain wrote: We could use some more infrastructure here. (1) A 'make randomconfig' tool that generates a random configuration. (2) Make the architecture a configuration variable (!) (3) A collection of RPM's so that people can download and install all the cross tools easily. (0) knowledge that CONFIG_FOO15 doesn't affect anything other than set of source files being compiled. Providing better tools is nice, but simplifying the problem domain sometimes pays better... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Michael Elizabeth Chastain wrote: We could use some more infrastructure here. (1) A 'make randomconfig' tool that generates a random configuration. There already are people that do this. The problem is that developers are lazy. All good programmers are lazy. They want to fix the problem - they don't want to wait for a day or two until all combinations have been tested. They want a "grep"-like thing. Not that it matters much. In the end, non-compiling kernel versions are quite acceptable as they fix bugs and they'll get fixed themselves eventually. So this is not probably that big of an issue in real life. Just a beauty wart. (2) Make the architecture a configuration variable (!) Why? You still need to have all the damn cross-compilers etc. At which point being a configuration variable is the _least_ of your worries. You're better off with just a new tree. (3) A collection of RPM's so that people can download and install all the cross tools easily. Hey, maybe you have a few 18GB disks lying around, but none of the machines I use every day could afford to have another 5-6 cross- compilation environments lying around. It's just not practical. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Linus writes ... mec (2) Make the architecture a configuration variable (!) linus Why? The real reason is that it's the right thing to do. Part of a configuration is "what machine it's for". Here are some benefits: (a) Arjan's testing machinery would catch problems in all architectures, not just the x86. (b The sparc / sparc64 people can manage their builds a lot easier. (c) With separate source and build trees, which I've implemented, it becomes a lot more feaasible to manage kernel builds for multiple platforms. Hey, maybe you have a few 18GB disks lying around, but none of the machines I use every day could afford to have another 5-6 cross- compilation environments lying around. It's just not practical. So don't do it. You build with your favorite configuration, and I'll build with my favorite 100 configurations. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Alexander Viro wrote: On Wed, 6 Sep 2000, Michael Elizabeth Chastain wrote: We could use some more infrastructure here. (1) A 'make randomconfig' tool that generates a random configuration. (2) Make the architecture a configuration variable (!) (3) A collection of RPM's so that people can download and install all the cross tools easily. (0) knowledge that CONFIG_FOO15 doesn't affect anything other than set of source files being compiled. Providing better tools is nice, but simplifying the problem domain sometimes pays better... IRONY ON So may I just suggest to repleace the usage of cpp at all with something more suitable for the task at hand and with a much more regular/stringent syntax better fitting into the syntax of the pure C language like m4 for example? /IRONY OFF EVEN MORE IRONY ON I think Java has the perfect solution for conditional compilation - don't make it possible at al in a sane standard way! Coditional compilation is evil like gotos (despite the fact that even every pascal implementation out there provided them). /EVEN MORE IRONY OFF The main problem with the CONFIG_ blah's isn't either the syntax nor they current usage - the problem is inherent to the simple fact that the number of possible combinations is of a very high order due to simple combinatorics. Hmm maybe the first irony is a quite serious suggestion at least in the case of CONFIG_ options? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Alexander Viro wrote:
On 6 Sep 2000, Linus Torvalds wrote:
However, what I think Al Viro dislikes about this is that it does tend
to leave code that won't compile, just because some of the accesses are
in places that the compiler doesn't see due to the pre-processor (or due
to other build-rules: like in architectures that aren't the one that the
developer uses).
Add "and that broken code gets fixed in utterly bogus ways 20 versions
down the road, when nobody remembers WTF had happened". Repeat several
times (and rarely-used parts _will_ accumulate such crap) and you've got
Lovecraftian beasts lurking in the tree. To some extent it's inevitable,
but frequency of such events matters...
... or they get #if 0'd, as in the case below:
diff -urN rc8-5/arch/mips64/kernel/linux32.c rc8-5-mips/arch/mips64/kernel/linux32.c
--- rc8-5/arch/mips64/kernel/linux32.c Thu Jul 27 21:36:54 2000
+++ rc8-5-mips/arch/mips64/kernel/linux32.c Wed Sep 6 13:59:36 2000
@@ -275,30 +275,33 @@
int do_execve32(char * filename, u32 * argv, u32 * envp, struct pt_regs * regs)
{
struct linux_binprm bprm;
- struct dentry * dentry;
+ struct file *file;
int retval;
int i;
- bprm.p = PAGE_SIZE*MAX_ARG_PAGES-sizeof(void *);
- memset(bprm.page, 0, MAX_ARG_PAGES*sizeof(bprm.page[0]));
+ file = open_exec(filename);
- dentry = open_namei(filename, 0, 0);
- retval = PTR_ERR(dentry);
- if (IS_ERR(dentry))
+ retval = PTR_ERR(file);
+ if (IS_ERR(file))
return retval;
- bprm.dentry = dentry;
+ bprm.p = PAGE_SIZE*MAX_ARG_PAGES-sizeof(void *);
+ memset(bprm.page, 0, MAX_ARG_PAGES*sizeof(bprm.page[0]));
+
+ bprm.file = file;
bprm.filename = filename;
bprm.sh_bang = 0;
bprm.loader = 0;
bprm.exec = 0;
if ((bprm.argc = count32(argv, bprm.p / sizeof(u32))) 0) {
- dput(dentry);
+ allow_write_access(file);
+ fput(file);
return bprm.argc;
}
if ((bprm.envc = count32(envp, bprm.p / sizeof(u32))) 0) {
- dput(dentry);
+ allow_write_access(file);
+ fput(file);
return bprm.envc;
}
@@ -326,8 +329,9 @@
out:
/* Something went wrong, return the inode and free the argument pages*/
- if (bprm.dentry)
- dput(bprm.dentry);
+ allow_write_access(bprm.file);
+ if (bprm.file)
+ fput(bprm.file);
/* Assumes that free_page() can take a NULL argument. */
/* I hope this is ok for all architectures */
I suspect that after that patch #if 0 around the whole mess may go to
hell. Ralf?
Notice that in this case code simply was not available in the tree when
changes were done. Right now I've just repeated the grep done back in May
and it brought the instances above. Folks, it didn't compile for 4
months...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Martin Dalecki wrote: IRONY ON So may I just suggest to repleace the usage of cpp at all with something more suitable for the task at hand and with a much more regular/stringent syntax better fitting into the syntax of the pure C language like m4 for example? /IRONY OFF No. Still "better tools" variant. Check blk_dev_init() and tell me how do you like the end of this function (drivers/block/ll_rw_blk.c). BTW, check how many of these CONFIG_... are needed anywhere on C level. Hint: see module_init macro. EVEN MORE IRONY ON I think Java has the perfect solution for conditional compilation - don't make it possible at al in a sane standard way! Coditional compilation is evil like gotos (despite the fact that even every pascal implementation out there provided them). /EVEN MORE IRONY OFF The main problem with the CONFIG_ blah's isn't either the syntax nor they current usage - the problem is inherent to the simple fact that the number of possible combinations is of a very high order due to simple combinatorics. It's not a fact, it's a problem... It doesn't _have_ to be very high order on cc level. ld - sure, but that's much simpler to deal with. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Alexander Viro wrote: Add "and that broken code gets fixed in utterly bogus ways 20 versions down the road, when nobody remembers WTF had happened". Repeat several times (and rarely-used parts _will_ accumulate such crap) and you've got Lovecraftian beasts lurking in the tree. "Lovecraftian beasts". I like it. To some degree that also ends up showing that not many people seem to care about that particular beast. In the end, it might be phased out altogether - something that _has_ happened, exactly for these kinds of reasons. Who still remembers xiafs? We have 33 different filesystems in the kernel tree - something that is quite impressive, and something that I don't think anybody else has ever tried to support. But we could have had 34.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Alexander Viro wrote: On Wed, 6 Sep 2000, Martin Dalecki wrote: IRONY ON So may I just suggest to repleace the usage of cpp at all with something more suitable for the task at hand and with a much more regular/stringent syntax better fitting into the syntax of the pure C language like m4 for example? /IRONY OFF No. Still "better tools" variant. Check blk_dev_init() and tell me how do you like the end of this function (drivers/block/ll_rw_blk.c). BTW, check Yes you are right here I don't like this particular piece of code in esp since: 1. The macro hackery may very well be replaced with "vanishing macros" at the declaration level. 2. This is basically an fully unrolled loop of calls into a function pointer table. 3. It's making the corresponding driver code non self contained. how many of these CONFIG_... are needed anywhere on C level. Hint: see module_init macro. Yes I like the introduction of the ld hackere there very much: It's basically solving the problems 1. 2. and 3. by doing the proper thing ;-) i.e. provide an statically initialized list of addresses and call them out of a loop. The main problem with the CONFIG_ blah's isn't either the syntax nor they current usage - the problem is inherent to the simple fact that the number of possible combinations is of a very high order due to simple combinatorics. It's not a fact, it's a problem... It doesn't _have_ to be very high order on cc level. ld - sure, but that's much simpler to deal with. But in some cases the driver api in linux are not quite supportiv for this. Please have a look at the strattegy routine (please allow me to use the proper UNIX terminology here ;-) declaration hackery inside of ide.h, oh sorry it gote moved and I can't quite find it again... ;-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Date:Wed, 6 Sep 2000 08:59:56 -0600 From: Richard Gooch [EMAIL PROTECTED] Jamie Lokier writes: Sorry, there's a GCC policy decision against putting it into a shared library. Why? Because this allows proprietary software vendor X to write closed-source compiler backend Y using GCC to provide the front end. If it never becomes a shared library, this sort of thing cannot happen. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Richard Gooch wrote: > > It will probably take about 5 years after a new version of GCC which > has this fix before we can trust it to produce correct code for the > kernel. I don't think it's that bad, Richard. As davem points out, the dead code elimination works OK. Chris has a counter-example but I was not able to reproduce that with 2.7.2.3. The only problem I'm aware of is this tendency to leave dangling strings in .rodata. Unfortunately you can't work around this with the linker and -fdata-sections either. See http://gcc.gnu.org/ml/gcc-prs/2000-q2/msg00036.html But still, doing the conditional compilation at compile-time rather than preprocessing-time is so *nice* that if you don't have too many literal strings floating about it may be justifiable. In cs89x0.c you reduce the object size by 1.5k by setting DEBUGGING to literal zero - no #ifdefs in sight. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Martin Dalecki wrote: >Basically I will just guess: The next maybe non free version of >source navigator will use the mechanism I have just described above. >So maybe there is already someone at RedHat doing exactly this work >already ;-). Source Navigator is GPL open source now, and has been for a while. ftp://sourceware.cygnus.com/pub/sourcenav/releases -- Mike A. Harris Linux advocate Computer Consultant GNU advocate Capslock Consulting Open Source advocate "Facts do not cease to exist because they are ignored." - Aldous Huxley - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Alexander Viro writes:
>
>
>
> On Wed, 6 Sep 2000, Andrew Morton wrote:
>
> > > cat t.c
> > foo()
> > {
> > if (0)
> > bar("hhh");
> > }
> > > gcc -O2 -c t.c
> > > strings t.o | grep hhh
> > hhh
Nasty, eh?
> Eww... Do they _ever_ remove dead code?
I guess not. Also, even if we get the compilers fixed, it will be some
time before we can deploy the kind of change you're proposing (which I
do agree looks a lot nicer: #ifdefs are ugly if for no other reason
that they lie outside the brace levels).
It will probably take about 5 years after a new version of GCC which
has this fix before we can trust it to produce correct code for the
kernel.
Regards,
Richard
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Date:Tue, 5 Sep 2000 21:32:45 -0400 (EDT) From: Alexander Viro <[EMAIL PROTECTED]> On Wed, 6 Sep 2000, Andrew Morton wrote: > > gcc -O2 -c t.c > > strings t.o | grep hhh > hhh Eww... Do they _ever_ remove dead code? They remove the code, they just forget to mark the string in the data section as unused and thus still emit it. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Andrew Morton wrote:
> > cat t.c
> foo()
> {
> if (0)
> bar("hhh");
> }
> > gcc -O2 -c t.c
> > strings t.o | grep hhh
> hhh
Eww... Do they _ever_ remove dead code?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Alexander Viro wrote:
>
>
> if (CONFIG_FOO) {
>
> } else {
>
> }
There are a zillion reasons why this technique is superior
to using `#ifdef CONFIG_FOO'. But, alas, gcc fumbles
the ball:
> cat t.c
foo()
{
if (0)
bar("hhh");
}
> gcc -O2 -c t.c
> strings t.o | grep hhh
hhh
This was raised with the gcc guys 4-5 weeks ago
and might now be fixed. I'm too bandwidth-deprived
to check.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Chris Wedgwood wrote:
> Oh, yes there is.
>
> if (CONFIG_FOO) {
>
> } else {
>
> }
>
> gcc can optimize that away and parser will see the whole thing.
>
> I'm not sure I like this construct either.
>
> Yes, it does mean gcc makes all the decisions and allows the
> c-compiler to to more checking (as opposed to the preprocessor which
> obviosly is really dumb) but it also assumes the compiler will always
> elimiate dead code and I'm not convinced it's any more readable that
> have "#if foo" scattered through the code.
If gcc will _ever_ fail to optimize away else in
if (1) {
...
} else {
...
}
- it's a bug in gcc. Sorry. Checking for the absence of code paths that would
lead into block in question is trivial. I suspect that if you can demonstrate
such example to gcc folks they will consider it as an obvious bug.
As readability - it's definitely at least as readable as
#if[def]. It also provides more consistent syntax. And when you are
using ifdef to violate scoping - your code is in need of rewrite anyway.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Martin Dalecki wrote:
> Alexander Viro wrote:
> >
> > On Wed, 6 Sep 2000, Martin Dalecki wrote:
> >
> > > Easy - the same way you do for cross compilation. Basically just:
> > >
> > > export CC=g++ --some-magic-long-option-i-dont-remember; make
> >
> > ... and you still have only a subset of the tree, simply because it is fed
> > through cpp before it reaches the parser. And cpp cuts away many pieces.
> > Different config options and you've got a different subset. Good luck
> > providing the coverage.
>
> That's not quite the problem - with the exception of the boundary cases
> of compleatly broken CONFIG_BLAH combinations... You have the fine
> .confg file there you know... Count them n and take the n! for all the
> possible config choices. Then you will see that THERE CAN'T be any
> better
> automatic approach then just what I have described above (ie. going
> directly into the compiler) and doing the CONFIG_ handling by hand.
> (I mean scripting for the most appriopriate choices...)
Oh, yes there is.
if (CONFIG_FOO) {
} else {
}
gcc can optimize that away and parser will see the whole thing.
> > > Basically I will just guess: The next maybe non free version of
> > > source navigator will use the mechanism I have just described above.
> > > So maybe there is already someone at RedHat doing exactly this work
> > > already ;-).
> >
> > Physically impossible without a major cleanup of the tree.
>
> Yeah... let me be nice to you as well Source Navigator got released
> for free - since the project died inside RedHat anyway due to the
> fact that it's full of the worst coding practices I ever saw - like
> for example literally copy and paste Tcl/Tk/iTcl and such. So instead
> of buring it they just threw it "out of the window" for "free".
>
WTF _is_ Source Navigator? I'm not kidding - I have no idea what the thing
is. My IDE is nvi and I don't touch userland code I don't use. World is
full of crappy code, so I don't particulary care for random GUI stuff, no
matter where it comes from.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Alexander Viro wrote: > > On Wed, 6 Sep 2000, Martin Dalecki wrote: > > > Easy - the same way you do for cross compilation. Basically just: > > > > export CC=g++ --some-magic-long-option-i-dont-remember; make > > ... and you still have only a subset of the tree, simply because it is fed > through cpp before it reaches the parser. And cpp cuts away many pieces. > Different config options and you've got a different subset. Good luck > providing the coverage. That's not quite the problem - with the exception of the boundary cases of compleatly broken CONFIG_BLAH combinations... You have the fine .confg file there you know... Count them n and take the n! for all the possible config choices. Then you will see that THERE CAN'T be any better automatic approach then just what I have described above (ie. going directly into the compiler) and doing the CONFIG_ handling by hand. (I mean scripting for the most appriopriate choices...) > > Basically I will just guess: The next maybe non free version of > > source navigator will use the mechanism I have just described above. > > So maybe there is already someone at RedHat doing exactly this work > > already ;-). > > Physically impossible without a major cleanup of the tree. Yeah... let me be nice to you as well Source Navigator got released for free - since the project died inside RedHat anyway due to the fact that it's full of the worst coding practices I ever saw - like for example literally copy and paste Tcl/Tk/iTcl and such. So instead of buring it they just threw it "out of the window" for "free". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Martin Dalecki wrote: > Easy - the same way you do for cross compilation. Basically just: > > export CC=g++ --some-magic-long-option-i-dont-remember; make ... and you still have only a subset of the tree, simply because it is fed through cpp before it reaches the parser. And cpp cuts away many pieces. Different config options and you've got a different subset. Good luck providing the coverage. > And then the normal compilation is not just generating *.o files, but > files with dumped parser trees as well. Hell It's even documented there! Yeah... May I suggest you to take info on gcc and look for references to preprocessor? > Basically I will just guess: The next maybe non free version of > source navigator will use the mechanism I have just described above. > So maybe there is already someone at RedHat doing exactly this work > already ;-). Physically impossible without a major cleanup of the tree. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Tue, Sep 05, 2000 at 07:19:11PM -0400, Peter Rival wrote: > Linus Torvalds wrote: > > > On Wed, 6 Sep 2000, Chris Wedgwood wrote: > > > > > > There are several other structures that have the same problem; very > > > generic sounding members. I wonder would a patch changing struct page > > > to something like this be acceptable? > > > > No. > > > > What would be acceptable is something that understands C, and that can be > > used to follow these things. Like "tags". > > > > How about something like cscope? It's sort of backwards if you're used to > tags, but I use it all the time here and have found it pretty useful in areas > that I'm not familiar with. Once they teach it how to handle assembly files > (they may have already, I don't know) it should be great for the kernel. cscope does not know much more about C than tags (like some regexpr hacks to detect declarations and calls) What Chris wants is really something only the compiler could do: log every reference of a pointer type to a file including line number. Then you could you could look for all references to "struct page *" as a type (be it from a variable or from a cast). This would be much more information than even -gdwarf2 includes, probably not much less than a full parse tree. It also could not catch references from assembly files. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Linus Torvalds wrote: > > On Tue, 5 Sep 2000, Alexander Viro wrote: > > > > > > What would be acceptable is something that understands C, and that can be > > > used to follow these things. Like "tags". > > > > I don't like hungarian notation too, but tags is out of question, > > unfortunately. Too much preprocessor abuse in include/*/*.h. > > Notice the _like_ tags. > > Basically, what I'm saying is that I understand why people want to grep > for specific uses, but I'm saying that a pure textual greap that doesn't > understand the context is not an option - because it implies adding > "cruft" to everything you want to grep for. Not for readability, but for > greppability. > > And I'm saying that if people really want to do this, then use the > computer to do it for you, having more than just "grep", and making your > tools aware of it. There is some facility allowing to implement this kind of things in the C++ part of the most recent EGCS version which makes implementing such things "relatively" easy - basiclly there is the provision to dump the parser trees as easy to process ascii text already there. Basically I think this dererr of syntactical analysis can only be implementen by serious help from the compiler. Maybe this is a new argument to facilitate at least correct syntactical processing of the kernel by the C++ flavour of EGCS? Please note that this wouldn't need to generate really executable code - which as we all know is rather difficult due to the extensive runtime support as well as ehm. the wired calling conventions C++ is oppressing on the compiler... Just correct syntactical processing is all what's neccessary - this isn't THAT difficult to achive ;-). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Chris Wedgwood wrote: > > There are several other structures that have the same problem; very > generic sounding members. I wonder would a patch changing struct page > to something like this be acceptable? No. What would be acceptable is something that understands C, and that can be used to follow these things. Like "tags". I do not like hungarian notion. I do not agree with making names easy to grep for. I like _human_ readable source code. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Tue, 5 Sep 2000, Linus Torvalds wrote: > > > On Wed, 6 Sep 2000, Chris Wedgwood wrote: > > > > There are several other structures that have the same problem; very > > generic sounding members. I wonder would a patch changing struct page > > to something like this be acceptable? > > No. > > What would be acceptable is something that understands C, and that can be > used to follow these things. Like "tags". > > I do not like hungarian notion. I do not agree with making names easy to > grep for. I like _human_ readable source code. I don't like hungarian notation too, but tags is out of question, unfortunately. Too much preprocessor abuse in include/*/*.h. Besides, tags doesn't distinguish structure types, IIRC - same problem as with grep (notice the pattern I've used - it weeds out everything not in the "field of some structure" contexts). The _real_ problem is preprocessor abuse. BTW, could we schedule for 2.5 the following? * things like CONFIG_FOO are _always_ defined. As 0 or 1, that is. * #ifdef CONFIG_FOO => if (CONFIG_FOO) in *.c. gcc will kill the unused branches just fine. * Yes, Virginia, it means that controlflow-affecting expansion has to go. Good riddance, IMO. Goal: making sure that every bloody line of the files we choose to compile goes through the parser. Will do wonders with test coverage and will make analysis tools like tags viable. Then we can just use the gcc frontend output as input for such beasts. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Chris Wedgwood wrote:
> On Tue, Sep 05, 2000 at 04:15:29PM -0400, Alexander Viro wrote:
>
> 2.5 the following?
> * things like CONFIG_FOO are _always_ defined. As 0 or 1, that is.
> * #ifdef CONFIG_FOO => if (CONFIG_FOO) in *.c. gcc will kill the unused
> branches just fine.
> * Yes, Virginia, it means that controlflow-affecting expansion has to
> go. Good riddance, IMO.
>
> * simple #define foo(x,y) definitions should be reimplemented as inline
> functions?
>
> In general -- make the compile more aware of the surroundings by
> utilising the preprocessor less and less?
Exactly. Look: cpp(1) is at least Homsky-1 complete. You really don't want to
emulate all possible expansions. OTOH, C parsers are easily available.
Moreover, the parser used by normal build process can be asked to give the
intermediate results, so attaching tags-like tools to it is feasible. So if
we can get full source seen by gcc - we've won the hardest part of the battle.
In most cases it's relatively easy (garden-variety conditional compilation is
not a problem, since if (CONSTANT) { } else { } is recognized by gcc). In
some... Well, just look at the text below and see if it deserves fixing:
static void __init cyrix_arr_init(void)
{
struct set_mtrr_context ctxt;
unsigned char ccr[7];
int ccrc[7] = { 0, 0, 0, 0, 0, 0, 0 };
#ifdef CONFIG_SMP
int i;
#endif
[snip]
#ifdef CONFIG_SMP
for(i=0; i<7; i++) ccr_state[i] = ccr[i];
for(i=0; i<8; i++)
cyrix_get_arr(i,
_state[i].base, _state[i].size, _state[i].type);
#endif
[snip]
}
Do you like it? Me neither. Now, if the thing turns into (preserving
ugly indent style)
static void __init cyrix_arr_init(void)
{
struct set_mtrr_context ctxt;
unsigned char ccr[7];
int ccrc[7] = { 0, 0, 0, 0, 0, 0, 0 };
[snip]
if (CONFIG_SMP) {
int i;
for(i=0; i<7; i++) ccr_state[i] = ccr[i];
for(i=0; i<8; i++)
cyrix_get_arr(i,
_state[i].base, _state[i].size, _state[i].type);
}
[snip]
}
- much more readable. And that's relatively sane example, BTW. There are
much uglier ones. The worst I remember was for (...) vs. if (...) before
the body, depending on value of the constant and bunch of #ifs on the same
constant in said body. IMO unknown author deserves rectal insertion of K
(The Practice of Programming). Rectal since that's apparently the shortest
way to his head...
I also remember "it doesn't compile - compiles fine here" threads. Lots of
them. In many cases it boiled down to the trivial syntax error ifdefed out
in almost all configurations.
Yes, some use of #ifdef is probably necessary. But 99% of the current use
is completely gratitious.
Don't get me wrong, I'm not calling for throwing cpp(1) away. But we are
using the thing in places where we have better replacements and we are
paying for that.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Chris Wedgwood wrote: There are several other structures that have the same problem; very generic sounding members. I wonder would a patch changing struct page to something like this be acceptable? No. What would be acceptable is something that understands C, and that can be used to follow these things. Like "tags". I do not like hungarian notion. I do not agree with making names easy to grep for. I like _human_ readable source code. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Linus Torvalds wrote: On Tue, 5 Sep 2000, Alexander Viro wrote: What would be acceptable is something that understands C, and that can be used to follow these things. Like "tags". I don't like hungarian notation too, but tags is out of question, unfortunately. Too much preprocessor abuse in include/*/*.h. Notice the _like_ tags. Basically, what I'm saying is that I understand why people want to grep for specific uses, but I'm saying that a pure textual greap that doesn't understand the context is not an option - because it implies adding "cruft" to everything you want to grep for. Not for readability, but for greppability. And I'm saying that if people really want to do this, then use the computer to do it for you, having more than just "grep", and making your tools aware of it. There is some facility allowing to implement this kind of things in the C++ part of the most recent EGCS version which makes implementing such things "relatively" easy - basiclly there is the provision to dump the parser trees as easy to process ascii text already there. Basically I think this dererr of syntactical analysis can only be implementen by serious help from the compiler. Maybe this is a new argument to facilitate at least correct syntactical processing of the kernel by the C++ flavour of EGCS? Please note that this wouldn't need to generate really executable code - which as we all know is rather difficult due to the extensive runtime support as well as ehm. the wired calling conventions C++ is oppressing on the compiler... Just correct syntactical processing is all what's neccessary - this isn't THAT difficult to achive ;-). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Tue, Sep 05, 2000 at 07:19:11PM -0400, Peter Rival wrote: Linus Torvalds wrote: On Wed, 6 Sep 2000, Chris Wedgwood wrote: There are several other structures that have the same problem; very generic sounding members. I wonder would a patch changing struct page to something like this be acceptable? No. What would be acceptable is something that understands C, and that can be used to follow these things. Like "tags". How about something like cscope? It's sort of backwards if you're used to tags, but I use it all the time here and have found it pretty useful in areas that I'm not familiar with. Once they teach it how to handle assembly files (they may have already, I don't know) it should be great for the kernel. cscope does not know much more about C than tags (like some regexpr hacks to detect declarations and calls) What Chris wants is really something only the compiler could do: log every reference of a pointer type to a file including line number. Then you could you could look for all references to "struct page *" as a type (be it from a variable or from a cast). This would be much more information than even -gdwarf2 includes, probably not much less than a full parse tree. It also could not catch references from assembly files. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Martin Dalecki wrote: Easy - the same way you do for cross compilation. Basically just: export CC=g++ --some-magic-long-option-i-dont-remember; make ... and you still have only a subset of the tree, simply because it is fed through cpp before it reaches the parser. And cpp cuts away many pieces. Different config options and you've got a different subset. Good luck providing the coverage. And then the normal compilation is not just generating *.o files, but files with dumped parser trees as well. Hell It's even documented there! Yeah... May I suggest you to take info on gcc and look for references to preprocessor? Basically I will just guess: The next maybe non free version of source navigator will use the mechanism I have just described above. So maybe there is already someone at RedHat doing exactly this work already ;-). Physically impossible without a major cleanup of the tree. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Alexander Viro wrote: On Wed, 6 Sep 2000, Martin Dalecki wrote: Easy - the same way you do for cross compilation. Basically just: export CC=g++ --some-magic-long-option-i-dont-remember; make ... and you still have only a subset of the tree, simply because it is fed through cpp before it reaches the parser. And cpp cuts away many pieces. Different config options and you've got a different subset. Good luck providing the coverage. That's not quite the problem - with the exception of the boundary cases of compleatly broken CONFIG_BLAH combinations... You have the fine .confg file there you know... Count them n and take the n! for all the possible config choices. Then you will see that THERE CAN'T be any better automatic approach then just what I have described above (ie. going directly into the compiler) and doing the CONFIG_ handling by hand. (I mean scripting for the most appriopriate choices...) Basically I will just guess: The next maybe non free version of source navigator will use the mechanism I have just described above. So maybe there is already someone at RedHat doing exactly this work already ;-). Physically impossible without a major cleanup of the tree. Yeah... let me be nice to you as well Source Navigator got released for free - since the project died inside RedHat anyway due to the fact that it's full of the worst coding practices I ever saw - like for example literally copy and paste Tcl/Tk/iTcl and such. So instead of buring it they just threw it "out of the window" for "free". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Chris Wedgwood wrote:
Oh, yes there is.
if (CONFIG_FOO) {
} else {
}
gcc can optimize that away and parser will see the whole thing.
I'm not sure I like this construct either.
Yes, it does mean gcc makes all the decisions and allows the
c-compiler to to more checking (as opposed to the preprocessor which
obviosly is really dumb) but it also assumes the compiler will always
elimiate dead code and I'm not convinced it's any more readable that
have "#if foo" scattered through the code.
If gcc will _ever_ fail to optimize away else in
if (1) {
...
} else {
...
}
- it's a bug in gcc. Sorry. Checking for the absence of code paths that would
lead into block in question is trivial. I suspect that if you can demonstrate
such example to gcc folks they will consider it as an obvious bug.
As readability - it's definitely at least as readable as
#if[def]. It also provides more consistent syntax. And when you are
using ifdef to violate scoping - your code is in need of rewrite anyway.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Alexander Viro wrote:
if (CONFIG_FOO) {
} else {
}
There are a zillion reasons why this technique is superior
to using `#ifdef CONFIG_FOO'. But, alas, gcc fumbles
the ball:
cat t.c
foo()
{
if (0)
bar("hhh");
}
gcc -O2 -c t.c
strings t.o | grep hhh
hhh
This was raised with the gcc guys 4-5 weeks ago
and might now be fixed. I'm too bandwidth-deprived
to check.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Andrew Morton wrote:
cat t.c
foo()
{
if (0)
bar("hhh");
}
gcc -O2 -c t.c
strings t.o | grep hhh
hhh
Eww... Do they _ever_ remove dead code?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Alexander Viro writes:
On Wed, 6 Sep 2000, Andrew Morton wrote:
cat t.c
foo()
{
if (0)
bar("hhh");
}
gcc -O2 -c t.c
strings t.o | grep hhh
hhh
Nasty, eh?
Eww... Do they _ever_ remove dead code?
I guess not. Also, even if we get the compilers fixed, it will be some
time before we can deploy the kind of change you're proposing (which I
do agree looks a lot nicer: #ifdefs are ugly if for no other reason
that they lie outside the brace levels).
It will probably take about 5 years after a new version of GCC which
has this fix before we can trust it to produce correct code for the
kernel.
Regards,
Richard
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Wed, 6 Sep 2000, Martin Dalecki wrote: Basically I will just guess: The next maybe non free version of source navigator will use the mechanism I have just described above. So maybe there is already someone at RedHat doing exactly this work already ;-). Source Navigator is GPL open source now, and has been for a while. ftp://sourceware.cygnus.com/pub/sourcenav/releases -- Mike A. Harris Linux advocate Computer Consultant GNU advocate Capslock Consulting Open Source advocate "Facts do not cease to exist because they are ignored." - Aldous Huxley - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Richard Gooch wrote: It will probably take about 5 years after a new version of GCC which has this fix before we can trust it to produce correct code for the kernel. I don't think it's that bad, Richard. As davem points out, the dead code elimination works OK. Chris has a counter-example but I was not able to reproduce that with 2.7.2.3. The only problem I'm aware of is this tendency to leave dangling strings in .rodata. Unfortunately you can't work around this with the linker and -fdata-sections either. See http://gcc.gnu.org/ml/gcc-prs/2000-q2/msg00036.html But still, doing the conditional compilation at compile-time rather than preprocessing-time is so *nice* that if you don't have too many literal strings floating about it may be justifiable. In cs89x0.c you reduce the object size by 1.5k by setting DEBUGGING to literal zero - no #ifdefs in sight. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Date:Tue, 5 Sep 2000 21:32:45 -0400 (EDT) From: Alexander Viro [EMAIL PROTECTED] On Wed, 6 Sep 2000, Andrew Morton wrote: gcc -O2 -c t.c strings t.o | grep hhh hhh Eww... Do they _ever_ remove dead code? They remove the code, they just forget to mark the string in the data section as unused and thus still emit it. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM now?
Arjan van de Ven wrote: > > In article <[EMAIL PROTECTED]> you >wrote: > > > Well, the bug seems to exactly using the page after a "free_page()". Which > > is always a bug, but at least should be easy to fix. > > > I've considered making "free_page()" a macro something like > > > __free_page(x); > > x = NULL; > > Maybe the trick electric fence uses might work. efence unmaps the page from > the page tables... and of course the get_free_page function would have to > map it into the tables. Not for normal use, but for debugging it may help. Yes, in simple terms it's illegal to use a page when it's free and you want get an error if you do. It's something that will never happen in correct code, so this seems like an ideal thing to have as a debug option. I took a quick tour through the source and found that in the vast majority of cases free_page is called on a local variable just before returning. Nulling x doesn't do much - a smart optimizer would just remove that code. In these cases, nulling the pointer won't catch any mistakes, but unmapping the page quite possibly will. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM now?
Arjan van de Ven wrote: In article [EMAIL PROTECTED] you wrote: Well, the bug seems to exactly using the page after a "free_page()". Which is always a bug, but at least should be easy to fix. I've considered making "free_page()" a macro something like __free_page(x); x = NULL; Maybe the trick electric fence uses might work. efence unmaps the page from the page tables... and of course the get_free_page function would have to map it into the tables. Not for normal use, but for debugging it may help. Yes, in simple terms it's illegal to use a page when it's free and you want get an error if you do. It's something that will never happen in correct code, so this seems like an ideal thing to have as a debug option. I took a quick tour through the source and found that in the vast majority of cases free_page is called on a local variable just before returning. Nulling x doesn't do much - a smart optimizer would just remove that code. In these cases, nulling the pointer won't catch any mistakes, but unmapping the page quite possibly will. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Mon, 4 Sep 2000, Jamie Lokier wrote: > Alexander Viro wrote: > > > *((unsigned long *)()) = NULL; > > > > free_page(foo()) and we've got problems... > > Alan really meant > > *((unsigned long *)&(x)) = NULL; > > and screw you if it's not an lvalue. There's a lot of places that will need to be fixed after that. So many that we could as well change the prototype and pass the address explicitly - efforts will be comparable. Besides, we got a whole slew of aliases for free_pages(). Too bad that counter on struct page is impossible to grep for - (->|\.)[]*count\> gives more than 2600 instances ;-/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Alexander Viro wrote: > > *((unsigned long *)()) = NULL; > > free_page(foo()) and we've got problems... Alan really meant *((unsigned long *)&(x)) = NULL; and screw you if it's not an lvalue. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
On Sun, 3 Sep 2000, Alan Cox wrote: > > I've considered making "free_page()" a macro something like > > > > __free_pge(x); > > x = NULL; > > > > but that works only for lvalues, of course, and not all users are > > lvalue-users, so it's hard to do. But that would have caught this. > > Not that hard. (barf buckets at the ready) > > *((unsigned long *)()) = NULL; free_page(foo()) and we've got problems... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
> I've considered making "free_page()" a macro something like > > __free_pge(x); > x = NULL; > > but that works only for lvalues, of course, and not all users are > lvalue-users, so it's hard to do. But that would have caught this. Not that hard. (barf buckets at the ready) *((unsigned long *)()) = NULL; Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
