* any chance of 2.6.0-test*? @ 2003-01-10 16:10 William Lee Irwin III 2003-01-10 16:28 ` Dave Jones ` (2 more replies) 0 siblings, 3 replies; 173+ messages in thread From: William Lee Irwin III @ 2003-01-10 16:10 UTC (permalink / raw) To: torvalds; +Cc: linux-kernel Say, I've been having _smashing_ success with 2.5.x on the desktop and on big fat highmem umpteen-way SMP (NUMA even!) boxen, and I was wondering if you were considering 2.6.0-test* anytime soon. I'd love to get this stuff out for users to hammer on ASAP, and things are looking really good AFAICT. Any specific concerns/issues/wishlist items you want taken care of before doing it or is it a "generalized comfort level" kind of thing? Let me know, I'd be much obliged for specific directions to move in. Thanks, Bill ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-10 16:10 any chance of 2.6.0-test*? William Lee Irwin III @ 2003-01-10 16:28 ` Dave Jones 2003-01-10 16:41 ` Zwane Mwaikambo 2003-01-10 17:19 ` Alan Cox 2003-01-13 1:08 ` Michael Kingsbury 2 siblings, 1 reply; 173+ messages in thread From: Dave Jones @ 2003-01-10 16:28 UTC (permalink / raw) To: William Lee Irwin III, torvalds, linux-kernel On Fri, Jan 10, 2003 at 08:10:12AM -0800, William Lee Irwin III wrote: > Say, I've been having _smashing_ success with 2.5.x on the desktop and > on big fat highmem umpteen-way SMP (NUMA even!) boxen, and I was > wondering if you were considering 2.6.0-test* anytime soon. There's still a boatload of drivers that don't compile, a metric shitload of bits that never came over from 2.4 after I stopped doing it circa 2.4.18, a lot of little 'trivial' patches that got left by the wayside, and a load of 'strange' bits that still need nailing down (personally, I have two boxes that won't boot a 2.5 kernel currently (One was pnpbios related, other needs more investigation), and another that falls on its face after 10 minutes idle uptime. My p4-ht desktop box is the only one that runs 2.5 without any problems. I think we're a way off from a '2.6-test' phase personally, but instigating a harder 'code freeze' would probably be a good thing to do[1] Dave [1] Exemption granted for the bits not yet brought forward of course. -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-10 16:28 ` Dave Jones @ 2003-01-10 16:41 ` Zwane Mwaikambo 2003-01-10 17:08 ` Dave Jones 0 siblings, 1 reply; 173+ messages in thread From: Zwane Mwaikambo @ 2003-01-10 16:41 UTC (permalink / raw) To: Dave Jones; +Cc: William Lee Irwin III, torvalds, linux-kernel On Fri, 10 Jan 2003, Dave Jones wrote: > There's still a boatload of drivers that don't compile, > a metric shitload of bits that never came over from 2.4 after > I stopped doing it circa 2.4.18, a lot of little 'trivial' > patches that got left by the wayside, and a load of 'strange' bits > that still need nailing down (personally, I have two boxes > that won't boot a 2.5 kernel currently (One was pnpbios related, I had a problem with PCI init, pnpbios ordering at some point, but i haven't tried a kernel with pnpbios in a while. > other needs more investigation), and another that falls on its > face after 10 minutes idle uptime. My p4-ht desktop box is the only one > that runs 2.5 without any problems. Thats interesting, i have a laptop experiencing the same symptoms, i'll be looking at it over the weekend. Zwane -- function.linuxpower.ca ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-10 16:41 ` Zwane Mwaikambo @ 2003-01-10 17:08 ` Dave Jones 0 siblings, 0 replies; 173+ messages in thread From: Dave Jones @ 2003-01-10 17:08 UTC (permalink / raw) To: Zwane Mwaikambo; +Cc: William Lee Irwin III, torvalds, linux-kernel On Fri, Jan 10, 2003 at 11:41:48AM -0500, Zwane Mwaikambo wrote: > > other needs more investigation), and another that falls on its > > face after 10 minutes idle uptime. My p4-ht desktop box is the only one > > that runs 2.5 without any problems. > > Thats interesting, i have a laptop experiencing the same symptoms, i'll be > looking at it over the weekend. This is exactly the sort of thing I meant. There are still problems out there which a lot of people haven't reported, yet when they see someone else with that problem, suddenly the 'me too's come in. I'm hoping the bugzilla will help out for corelating these as it starts to get used more. Dave -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-10 16:10 any chance of 2.6.0-test*? William Lee Irwin III 2003-01-10 16:28 ` Dave Jones @ 2003-01-10 17:19 ` Alan Cox 2003-01-10 16:40 ` Jeff Garzik ` (3 more replies) 2003-01-13 1:08 ` Michael Kingsbury 2 siblings, 4 replies; 173+ messages in thread From: Alan Cox @ 2003-01-10 17:19 UTC (permalink / raw) To: William Lee Irwin III; +Cc: Linus Torvalds, Linux Kernel Mailing List On Fri, 2003-01-10 at 16:10, William Lee Irwin III wrote: > Any specific concerns/issues/wishlist items you want taken care of > before doing it or is it a "generalized comfort level" kind of thing? > Let me know, I'd be much obliged for specific directions to move in. IDE is all broken still and will take at least another three months to fix - before we get to 'improve'. The entire tty layer locking is terminally broken and nobody has even started fixing it. Just try a mass of parallel tty/pty activity . It was problematic before, pre-empt has taken it to dead, defunct and buried. Most of the drivers still don't build either. I think its important that we get to the stage that we can actually say - It compiles (as close to all the mainstream bits of it as possible) - The stuff that is destined for the bitbucket is marked in Config and people agree it should go - It works (certainly the common stuff) - Its statistically unlikely to eat your computer - It passes Cerberus uniprocessor and smp with/without pre-empt Otherwise everyone wil rapidly decide that ".0-pre" means ".0 as in Windows" at which point you've just destroyed your testing base. Given all the new stuff should be in, I'd like to see a Linus the meanie round of updating for a while which is simply about getting all the 2.4 fixes and the 2.5 driver compile bugs nailed, and if it doesn't fix a compile bug or a logic bug it doesn't go in. No more "ISAPnP TNG" and module rewrites please Alan ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-10 17:19 ` Alan Cox @ 2003-01-10 16:40 ` Jeff Garzik 2003-01-10 17:06 ` Dave Jones ` (2 subsequent siblings) 3 siblings, 0 replies; 173+ messages in thread From: Jeff Garzik @ 2003-01-10 16:40 UTC (permalink / raw) To: Alan Cox; +Cc: William Lee Irwin III, Linus Torvalds, Linux Kernel Mailing List On Fri, Jan 10, 2003 at 05:19:08PM +0000, Alan Cox wrote: > No more "ISAPnP TNG" and module rewrites please Highlighted and seconded... ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-10 17:19 ` Alan Cox 2003-01-10 16:40 ` Jeff Garzik @ 2003-01-10 17:06 ` Dave Jones 2003-01-10 17:25 ` Jeff Garzik ` (2 more replies) 2003-01-10 17:37 ` Jochen Friedrich 2003-01-12 9:27 ` Greg KH 3 siblings, 3 replies; 173+ messages in thread From: Dave Jones @ 2003-01-10 17:06 UTC (permalink / raw) To: Alan Cox; +Cc: William Lee Irwin III, Linus Torvalds, Linux Kernel Mailing List On Fri, Jan 10, 2003 at 05:19:08PM +0000, Alan Cox wrote: > Most of the drivers still don't build either. or still lack 2.4 fixes. > - The stuff that is destined for the bitbucket is marked in Config and people > agree it should go What's happening with the OSS drivers ? I'm still carrying a few hundred KB of changes from 2.4 for those. I'm not going to spent a day splitting them up, commenting them and pushing to Linus if we're going to be dropping various drivers. > - It passes Cerberus uniprocessor and smp with/without pre-empt I think this should wait until at least some more of the 2.4 changes come forward. Most of those are security issues and the likes, but there are a few driver corner cases too. > Otherwise everyone wil rapidly decide that ".0-pre" means ".0 as in Windows" > at which point you've just destroyed your testing base. agreed. > Given all the new stuff should be in, I'd like to see a Linus the meanie > round of updating for a while which is simply about getting all the 2.4 fixes > and the 2.5 driver compile bugs nailed, and if it doesn't fix a compile bug > or a logic bug it doesn't go in. Seconded. > No more "ISAPnP TNG" and module rewrites please Absolutly. Lets try and get 2.6 out the door _this_ year. Dave -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-10 17:06 ` Dave Jones @ 2003-01-10 17:25 ` Jeff Garzik 2003-01-10 17:29 ` Linus Torvalds 2003-01-10 18:16 ` any chance of 2.6.0-test*? Alan Cox 2 siblings, 0 replies; 173+ messages in thread From: Jeff Garzik @ 2003-01-10 17:25 UTC (permalink / raw) To: Dave Jones, Alan Cox, William Lee Irwin III, Linus Torvalds, Linux Kernel Mailing List On Fri, Jan 10, 2003 at 05:06:25PM +0000, Dave Jones wrote: > On Fri, Jan 10, 2003 at 05:19:08PM +0000, Alan Cox wrote: > What's happening with the OSS drivers ? > I'm still carrying a few hundred KB of changes from 2.4 for those. > I'm not going to spent a day splitting them up, commenting them and pushing > to Linus if we're going to be dropping various drivers. I've been updating the via audio every now and again. If sound/oss is staying for 2.6.0, we might as well merge the 2.4.x changes. Jeff ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-10 17:06 ` Dave Jones 2003-01-10 17:25 ` Jeff Garzik @ 2003-01-10 17:29 ` Linus Torvalds 2003-01-10 18:47 ` J.A. Magallon 2003-01-14 1:39 ` James H. Cloos Jr. 2003-01-10 18:16 ` any chance of 2.6.0-test*? Alan Cox 2 siblings, 2 replies; 173+ messages in thread From: Linus Torvalds @ 2003-01-10 17:29 UTC (permalink / raw) To: Dave Jones; +Cc: Alan Cox, William Lee Irwin III, Linux Kernel Mailing List On Fri, 10 Jan 2003, Dave Jones wrote: > > What's happening with the OSS drivers ? > I'm still carrying a few hundred KB of changes from 2.4 for those. > I'm not going to spent a day splitting them up, commenting them and pushing > to Linus if we're going to be dropping various drivers. I consider them to be old drivers, the same way "hd.c" was. Not necessarily useful for most people, but neither was hd.c. And it was around for a _long_ time (heh. I needed to check. The config option is still there ;) So I don't see a huge reason to remove them from the sources, but we might well make them harder to select by mistake, for example. Right now the config help files aren't exactly helpful, and the OSS choice is before the ALSA one, which looks wrong. They should probably be marked deprecated, and if they don't get a lot of maintenance, that's fine. Linus ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-10 17:29 ` Linus Torvalds @ 2003-01-10 18:47 ` J.A. Magallon 2003-01-10 19:37 ` Matthew D. Pitts 2003-01-10 19:51 ` Jeff Garzik 2003-01-14 1:39 ` James H. Cloos Jr. 1 sibling, 2 replies; 173+ messages in thread From: J.A. Magallon @ 2003-01-10 18:47 UTC (permalink / raw) To: linux-kernel On 2003.01.10 Linus Torvalds wrote: > > On Fri, 10 Jan 2003, Dave Jones wrote: > > > > What's happening with the OSS drivers ? > > I'm still carrying a few hundred KB of changes from 2.4 for those. > > I'm not going to spent a day splitting them up, commenting them and pushing > > to Linus if we're going to be dropping various drivers. > > I consider them to be old drivers, the same way "hd.c" was. Not > necessarily useful for most people, but neither was hd.c. And it was > around for a _long_ time (heh. I needed to check. The config option is > still there ;) > > So I don't see a huge reason to remove them from the sources, but we might > well make them harder to select by mistake, for example. Right now the > config help files aren't exactly helpful, and the OSS choice is before the > ALSA one, which looks wrong. > > They should probably be marked deprecated, and if they don't get a lot of > maintenance, that's fine. > > Linus As there is a CONFIG_EXPERIMENTAL, how about a CONFIG_DEPRECATED for the opposite edge ? -- J.A. Magallon <jamagallon@able.es> \ Software is like sex: werewolf.able.es \ It's better when it's free Mandrake Linux release 9.1 (Cooker) for i586 Linux 2.4.21-pre2-jam2 (gcc 3.2.1 (Mandrake Linux 9.1 3.2.1-2mdk)) ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-10 18:47 ` J.A. Magallon @ 2003-01-10 19:37 ` Matthew D. Pitts 2003-01-10 19:51 ` Jeff Garzik 1 sibling, 0 replies; 173+ messages in thread From: Matthew D. Pitts @ 2003-01-10 19:37 UTC (permalink / raw) To: linux-kernel > > They should probably be marked deprecated, and if they don't get a lot of > > maintenance, that's fine. > > > > Linus > > As there is a CONFIG_EXPERIMENTAL, how about a CONFIG_DEPRECATED for the > opposite edge ? > I heartly second this. And would be willing to do it when time permits. Matthew ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-10 18:47 ` J.A. Magallon 2003-01-10 19:37 ` Matthew D. Pitts @ 2003-01-10 19:51 ` Jeff Garzik 1 sibling, 0 replies; 173+ messages in thread From: Jeff Garzik @ 2003-01-10 19:51 UTC (permalink / raw) To: J.A. Magallon; +Cc: linux-kernel On Fri, Jan 10, 2003 at 07:47:39PM +0100, J.A. Magallon wrote: > As there is a CONFIG_EXPERIMENTAL, how about a CONFIG_DEPRECATED for the > opposite edge ? CONFIG_OBSOLETE already exists for this. ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-10 17:29 ` Linus Torvalds 2003-01-10 18:47 ` J.A. Magallon @ 2003-01-14 1:39 ` James H. Cloos Jr. 2003-01-15 21:46 ` [PATCH][RESEND w/ reasonable Subject] alsa before oss in Kconfig James H. Cloos Jr. 1 sibling, 1 reply; 173+ messages in thread From: James H. Cloos Jr. @ 2003-01-14 1:39 UTC (permalink / raw) To: Linus Torvalds; +Cc: Linux Kernel Mailing List [re OSS vs ALSA audio drivers] Linus> So I don't see a huge reason to remove them from the sources, Linus> but we might well make them harder to select by mistake, for Linus> example. Right now the config help files aren't exactly helpful, Linus> and the OSS choice is before the ALSA one, which looks wrong. Linus> They should probably be marked deprecated, and if they don't Linus> get a lot of maintenance, that's fine. Like this? Also available from: bk://cloos.bkbits.net/alsa-oss ChangeSet@1.966, 2003-01-13 20:05:11-05:00, cloos@lugabout.jhcloos.org Move ALSA before OSS sound/Kconfig | 26 ++++++++++++-------------- arch/i386/defconfig | 10 +++++----- arch/ia64/defconfig | 10 +++++----- arch/parisc/defconfig | 8 ++++---- arch/sparc64/defconfig | 10 +++++----- 5 files changed, 31 insertions(+), 33 deletions(-) diff -Nru a/sound/Kconfig b/sound/Kconfig --- a/sound/Kconfig Mon Jan 13 20:32:29 2003 +++ b/sound/Kconfig Mon Jan 13 20:32:29 2003 @@ -1,20 +1,6 @@ # sound/Config.in # -menu "Open Sound System" - depends on SOUND!=n - -config SOUND_PRIME - tristate "Open Sound System" - depends on SOUND - help - Say 'Y' or 'M' to enable Open Sound System drivers. - -source "sound/oss/Kconfig" - -endmenu - - menu "Advanced Linux Sound Architecture" depends on SOUND!=n @@ -42,3 +28,15 @@ endmenu +menu "Open Sound System" + depends on SOUND!=n + +config SOUND_PRIME + tristate "Open Sound System (DEPRECATED)" + depends on SOUND + help + Say 'Y' or 'M' to enable Open Sound System drivers. + +source "sound/oss/Kconfig" + +endmenu diff -Nru a/arch/i386/defconfig b/arch/i386/defconfig --- a/arch/i386/defconfig Mon Jan 13 20:32:29 2003 +++ b/arch/i386/defconfig Mon Jan 13 20:32:29 2003 @@ -839,11 +839,6 @@ CONFIG_SOUND=y # -# Open Sound System -# -# CONFIG_SOUND_PRIME is not set - -# # Advanced Linux Sound Architecture # CONFIG_SND=y @@ -922,6 +917,11 @@ # ALSA USB devices # # CONFIG_SND_USB_AUDIO is not set + +# +# Open Sound System +# +# CONFIG_SOUND_PRIME is not set # # USB support diff -Nru a/arch/ia64/defconfig b/arch/ia64/defconfig --- a/arch/ia64/defconfig Mon Jan 13 20:32:29 2003 +++ b/arch/ia64/defconfig Mon Jan 13 20:32:29 2003 @@ -657,6 +657,11 @@ CONFIG_SOUND=y # +# Advanced Linux Sound Architecture +# +# CONFIG_SND is not set + +# # Open Sound System # CONFIG_SOUND_PRIME=y @@ -679,11 +684,6 @@ # CONFIG_SOUND_VIA82CXXX is not set # CONFIG_SOUND_OSS is not set # CONFIG_SOUND_TVMIXER is not set - -# -# Advanced Linux Sound Architecture -# -# CONFIG_SND is not set # # USB support diff -Nru a/arch/parisc/defconfig b/arch/parisc/defconfig --- a/arch/parisc/defconfig Mon Jan 13 20:32:29 2003 +++ b/arch/parisc/defconfig Mon Jan 13 20:32:29 2003 @@ -643,14 +643,14 @@ CONFIG_SOUND=y # -# Open Sound System +# Advanced Linux Sound Architecture # -# CONFIG_SOUND_PRIME is not set +# CONFIG_SND is not set # -# Advanced Linux Sound Architecture +# Open Sound System # -# CONFIG_SND is not set +# CONFIG_SOUND_PRIME is not set # # USB support diff -Nru a/arch/sparc64/defconfig b/arch/sparc64/defconfig --- a/arch/sparc64/defconfig Mon Jan 13 20:32:29 2003 +++ b/arch/sparc64/defconfig Mon Jan 13 20:32:29 2003 @@ -710,11 +710,6 @@ CONFIG_SOUND=m # -# Open Sound System -# -# CONFIG_SOUND_PRIME is not set - -# # Advanced Linux Sound Architecture # CONFIG_SND=m @@ -777,6 +772,11 @@ # CONFIG_SND_SUN_AMD7930=m CONFIG_SND_SUN_CS4231=m + +# +# Open Sound System +# +# CONFIG_SOUND_PRIME is not set # # USB support ^ permalink raw reply [flat|nested] 173+ messages in thread
* [PATCH][RESEND w/ reasonable Subject] alsa before oss in Kconfig 2003-01-14 1:39 ` James H. Cloos Jr. @ 2003-01-15 21:46 ` James H. Cloos Jr. 0 siblings, 0 replies; 173+ messages in thread From: James H. Cloos Jr. @ 2003-01-15 21:46 UTC (permalink / raw) To: Linus Torvalds; +Cc: Linux Kernel Mailing List I should have changed the subject when I first sent this.... [re OSS vs ALSA audio drivers] Linus> So I don't see a huge reason to remove them from the sources, Linus> but we might well make them harder to select by mistake, for Linus> example. Right now the config help files aren't exactly helpful, Linus> and the OSS choice is before the ALSA one, which looks wrong. Linus> They should probably be marked deprecated, and if they don't Linus> get a lot of maintenance, that's fine. Like this? Also available from: bk://cloos.bkbits.net/alsa-oss ChangeSet@1.966, 2003-01-13 20:05:11-05:00, cloos@lugabout.jhcloos.org Move ALSA before OSS sound/Kconfig | 26 ++++++++++++-------------- arch/i386/defconfig | 10 +++++----- arch/ia64/defconfig | 10 +++++----- arch/parisc/defconfig | 8 ++++---- arch/sparc64/defconfig | 10 +++++----- 5 files changed, 31 insertions(+), 33 deletions(-) diff -Nru a/sound/Kconfig b/sound/Kconfig --- a/sound/Kconfig Mon Jan 13 20:32:29 2003 +++ b/sound/Kconfig Mon Jan 13 20:32:29 2003 @@ -1,20 +1,6 @@ # sound/Config.in # -menu "Open Sound System" - depends on SOUND!=n - -config SOUND_PRIME - tristate "Open Sound System" - depends on SOUND - help - Say 'Y' or 'M' to enable Open Sound System drivers. - -source "sound/oss/Kconfig" - -endmenu - - menu "Advanced Linux Sound Architecture" depends on SOUND!=n @@ -42,3 +28,15 @@ endmenu +menu "Open Sound System" + depends on SOUND!=n + +config SOUND_PRIME + tristate "Open Sound System (DEPRECATED)" + depends on SOUND + help + Say 'Y' or 'M' to enable Open Sound System drivers. + +source "sound/oss/Kconfig" + +endmenu diff -Nru a/arch/i386/defconfig b/arch/i386/defconfig --- a/arch/i386/defconfig Mon Jan 13 20:32:29 2003 +++ b/arch/i386/defconfig Mon Jan 13 20:32:29 2003 @@ -839,11 +839,6 @@ CONFIG_SOUND=y # -# Open Sound System -# -# CONFIG_SOUND_PRIME is not set - -# # Advanced Linux Sound Architecture # CONFIG_SND=y @@ -922,6 +917,11 @@ # ALSA USB devices # # CONFIG_SND_USB_AUDIO is not set + +# +# Open Sound System +# +# CONFIG_SOUND_PRIME is not set # # USB support diff -Nru a/arch/ia64/defconfig b/arch/ia64/defconfig --- a/arch/ia64/defconfig Mon Jan 13 20:32:29 2003 +++ b/arch/ia64/defconfig Mon Jan 13 20:32:29 2003 @@ -657,6 +657,11 @@ CONFIG_SOUND=y # +# Advanced Linux Sound Architecture +# +# CONFIG_SND is not set + +# # Open Sound System # CONFIG_SOUND_PRIME=y @@ -679,11 +684,6 @@ # CONFIG_SOUND_VIA82CXXX is not set # CONFIG_SOUND_OSS is not set # CONFIG_SOUND_TVMIXER is not set - -# -# Advanced Linux Sound Architecture -# -# CONFIG_SND is not set # # USB support diff -Nru a/arch/parisc/defconfig b/arch/parisc/defconfig --- a/arch/parisc/defconfig Mon Jan 13 20:32:29 2003 +++ b/arch/parisc/defconfig Mon Jan 13 20:32:29 2003 @@ -643,14 +643,14 @@ CONFIG_SOUND=y # -# Open Sound System +# Advanced Linux Sound Architecture # -# CONFIG_SOUND_PRIME is not set +# CONFIG_SND is not set # -# Advanced Linux Sound Architecture +# Open Sound System # -# CONFIG_SND is not set +# CONFIG_SOUND_PRIME is not set # # USB support diff -Nru a/arch/sparc64/defconfig b/arch/sparc64/defconfig --- a/arch/sparc64/defconfig Mon Jan 13 20:32:29 2003 +++ b/arch/sparc64/defconfig Mon Jan 13 20:32:29 2003 @@ -710,11 +710,6 @@ CONFIG_SOUND=m # -# Open Sound System -# -# CONFIG_SOUND_PRIME is not set - -# # Advanced Linux Sound Architecture # CONFIG_SND=m @@ -777,6 +772,11 @@ # CONFIG_SND_SUN_AMD7930=m CONFIG_SND_SUN_CS4231=m + +# +# Open Sound System +# +# CONFIG_SOUND_PRIME is not set # # USB support - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-10 17:06 ` Dave Jones 2003-01-10 17:25 ` Jeff Garzik 2003-01-10 17:29 ` Linus Torvalds @ 2003-01-10 18:16 ` Alan Cox 2 siblings, 0 replies; 173+ messages in thread From: Alan Cox @ 2003-01-10 18:16 UTC (permalink / raw) To: Dave Jones Cc: William Lee Irwin III, Linus Torvalds, Linux Kernel Mailing List On Fri, 2003-01-10 at 17:06, Dave Jones wrote: > What's happening with the OSS drivers ? > I'm still carrying a few hundred KB of changes from 2.4 for those. > I'm not going to spent a day splitting them up, commenting them and pushing > to Linus if we're going to be dropping various drivers. I'd hope they would go away but it seems that will be post 2.6. The drivers do seem to mostly work in 2.5.x. I'm meaning the stuff that doesn't compile and nobody gives a damn about. ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-10 17:19 ` Alan Cox 2003-01-10 16:40 ` Jeff Garzik 2003-01-10 17:06 ` Dave Jones @ 2003-01-10 17:37 ` Jochen Friedrich 2003-01-10 17:38 ` Linus Torvalds 2003-01-12 9:27 ` Greg KH 3 siblings, 1 reply; 173+ messages in thread From: Jochen Friedrich @ 2003-01-10 17:37 UTC (permalink / raw) To: Alan Cox; +Cc: William Lee Irwin III, Linus Torvalds, Linux Kernel Mailing List On 10 Jan 2003, Alan Cox wrote: > On Fri, 2003-01-10 at 16:10, William Lee Irwin III wrote: > > Any specific concerns/issues/wishlist items you want taken care of > > before doing it or is it a "generalized comfort level" kind of thing? > > Let me know, I'd be much obliged for specific directions to move in. > > IDE is all broken still and will take at least another three months to > fix - before we get to 'improve'. As is the whole frame buffer mess. USB slowly seems to return to a working state. ISDN seems to be a total mess, as well. > No more "ISAPnP TNG" and module rewrites please Full ACK. There are still archs without working module code, right now (parisc and mips come to my mind). --jochen ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-10 17:37 ` Jochen Friedrich @ 2003-01-10 17:38 ` Linus Torvalds 0 siblings, 0 replies; 173+ messages in thread From: Linus Torvalds @ 2003-01-10 17:38 UTC (permalink / raw) To: Jochen Friedrich Cc: Alan Cox, William Lee Irwin III, Linux Kernel Mailing List On Fri, 10 Jan 2003, Jochen Friedrich wrote: > > Full ACK. There are still archs without working module code, right now > (parisc and mips come to my mind). Note that other architectures have never been an issue for releasing new kernels, and that is _particularly_ true of architectures like parisc and mips that haven't even _tried_ to track development kernels. In fact, mips "anti-maintenance" has often actively discouraged people from even bothering to update mips code when adding new features. Linus ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-10 17:19 ` Alan Cox ` (2 preceding siblings ...) 2003-01-10 17:37 ` Jochen Friedrich @ 2003-01-12 9:27 ` Greg KH 2003-01-12 16:55 ` Alan Cox 2003-01-12 17:05 ` Linus Torvalds 3 siblings, 2 replies; 173+ messages in thread From: Greg KH @ 2003-01-12 9:27 UTC (permalink / raw) To: Alan Cox; +Cc: William Lee Irwin III, Linus Torvalds, Linux Kernel Mailing List On Fri, Jan 10, 2003 at 05:19:08PM +0000, Alan Cox wrote: > The entire tty layer locking is terminally broken and nobody has even > started fixing it. Just try a mass of parallel tty/pty activity . It > was problematic before, pre-empt has taken it to dead, defunct and > buried. I've looked into this, and wow, it's not a simple fix :( But this is really the first it's been mentioned, I can't see holding up 2.6 for this. It's a 2.7 job at the earliest, unless someone wants to step up and do it right now... thanks, greg k-h ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 9:27 ` Greg KH @ 2003-01-12 16:55 ` Alan Cox 2003-01-12 17:05 ` Linus Torvalds 1 sibling, 0 replies; 173+ messages in thread From: Alan Cox @ 2003-01-12 16:55 UTC (permalink / raw) To: Greg KH; +Cc: William Lee Irwin III, Linus Torvalds, Linux Kernel Mailing List On Sun, 2003-01-12 at 09:27, Greg KH wrote: > I've looked into this, and wow, it's not a simple fix :( > > But this is really the first it's been mentioned, I can't see holding up > 2.6 for this. It's a 2.7 job at the earliest, unless someone wants to > step up and do it right now... 2.5.x crashes erratically and randomly under high tty/pty load. At the moment I'm assuming this is the tty code. That means we can't decide not to fix it since its already fatally broken. Alan ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 9:27 ` Greg KH 2003-01-12 16:55 ` Alan Cox @ 2003-01-12 17:05 ` Linus Torvalds 2003-01-12 17:17 ` Christoph Hellwig 2003-01-12 17:37 ` Russell King 1 sibling, 2 replies; 173+ messages in thread From: Linus Torvalds @ 2003-01-12 17:05 UTC (permalink / raw) To: Greg KH; +Cc: Alan Cox, William Lee Irwin III, Linux Kernel Mailing List On Sun, 12 Jan 2003, Greg KH wrote: > > But this is really the first it's been mentioned, I can't see holding up > 2.6 for this. It's a 2.7 job at the earliest, unless someone wants to > step up and do it right now... Hmm.. The tty layer still depends on the kernel lock, and we're clearly not changing that at this point any more. I don't see what the fundamental problem is, it sounds like there's just some part that got the lock yanked, probably as part of the normal VFS kernel-lock-avoidance patches. Looking at tty_io.c (which pretty much drives everything else), it does seem to take the lock _most_ of the time, including read and write time. The only place that looked like it _really_ didn't get the kernel lock was apparently tty_open(), which is admittedly a fairly important part of it ;) Alan, do you have a test-load? Might be worth just renaming "tty_open()" to "do_tty_open()", and then do a tty_open(..) { lock_kernel(); retval = do_tty_open(..); unlock_kernel(); return retval; } thing. Quite frankly, very little has changed in the 2.5.x tty layer (serial stuff, yes, tty no), so its locking should work basically as well as 2.4.x does. Except for infrastructure changes like the VFS lock removal (where 2.4.x will hold the kernel lock itself over open, 2.5.x won't). Yeah, preemption has this tendency to show locking problems more easily, and it could clearly be the case that it's broken in 2.4.x too but basically impossible to trigger. But the _simple_ explanation is that tty_open() (and perhaps some other cases like ioctl) just missed the kernel lock. Linus ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 17:05 ` Linus Torvalds @ 2003-01-12 17:17 ` Christoph Hellwig 2003-01-12 19:15 ` Linus Torvalds 2003-01-12 17:37 ` Russell King 1 sibling, 1 reply; 173+ messages in thread From: Christoph Hellwig @ 2003-01-12 17:17 UTC (permalink / raw) To: Linus Torvalds Cc: Greg KH, Alan Cox, William Lee Irwin III, Linux Kernel Mailing List On Sun, Jan 12, 2003 at 09:05:16AM -0800, Linus Torvalds wrote: > The only place that looked like it _really_ didn't get the kernel lock was > apparently tty_open(), which is admittedly a fairly important part of it ;) 2.5 does hold the BKL on ->open of charater- (and block-) devices. The real problem is that the big irqlock is gone and mingo just replaced it with local_irq_save & friends, which is not enough. ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 17:17 ` Christoph Hellwig @ 2003-01-12 19:15 ` Linus Torvalds 2003-01-12 19:34 ` Rob Wilkens 2003-01-13 6:23 ` Greg KH 0 siblings, 2 replies; 173+ messages in thread From: Linus Torvalds @ 2003-01-12 19:15 UTC (permalink / raw) To: Christoph Hellwig Cc: Greg KH, Alan Cox, William Lee Irwin III, Linux Kernel Mailing List On Sun, 12 Jan 2003, Christoph Hellwig wrote: > > 2.5 does hold the BKL on ->open of charater- (and block-) devices. Ahh, my bad. > The real problem is that the big irqlock is gone and mingo just replaced > it with local_irq_save & friends, which is not enough. Ok, most of them should be fixable with a simple spinlock approach. If the recursion is too nasty to handle, we could make some tty-specific recursive spinlock as a stop-gap measure, and mark it as being destined for the garbage-heap in 2.7.x: /* * This isn't even _trying_ to be fast! */ struct recursive_spinlock { spinlock_t lock; int lock_count; struct task_struct *lock_owner; }; static struct recursive_spinlock tty_lock = { .lock = SPIN_LOCK_UNLOCKED, .lock_count = 0, .lock_owner = NULL }; unsigned long tty_spin_lock(void) { unsigned long flags; struct task_struct *tsk; local_irq_save(flags); preempt_disable(); tsk = current; if (spin_trylock(&tty_lock.lock)) goto got_lock; if (tsk == tty_lock.lock_owner) { WARN_ON(!tty_lock.lock_count); tty_lock.lock_count++; return flags; } spin_lock(&tty_lock.lock); got_lock: WARN_ON(tty_lock.lock_owner); WARN_ON(tty_lock.lock_count); tty_lock.lock_owner = tsk; tty_lock.lock_count = 1; return flags; } void tty_spin_unlock(unsigned long flags) { WARN_ON(tty_lock.lock_owner != current); WARN_ON(!tty_lock.lock_count); if (!--tty_lock.lock_count) { tty_lock.lock_owner = NULL; spin_unlock(&tty_lock.lock); } preempt_enable(); local_irq_restore(flags); } and be done with it. Anybody willing to test it and see if the above works? Linus ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 19:15 ` Linus Torvalds @ 2003-01-12 19:34 ` Rob Wilkens 2003-01-12 19:37 ` Rob Wilkens ` (7 more replies) 2003-01-13 6:23 ` Greg KH 1 sibling, 8 replies; 173+ messages in thread From: Rob Wilkens @ 2003-01-12 19:34 UTC (permalink / raw) To: Linus Torvalds Cc: Christoph Hellwig, Greg KH, Alan Cox, William Lee Irwin III, Linux Kernel Mailing List Linus, I'm REALLY opposed to the use of the word "goto" in any code where it's not needed. OF course, I'm a linux kernel newbie, so I'm in no position to comment Let me comment below the relevant code snippet below as to how I would change it: On Sun, 2003-01-12 at 14:15, Linus Torvalds wrote: > if (spin_trylock(&tty_lock.lock)) > goto got_lock; > if (tsk == tty_lock.lock_owner) { > WARN_ON(!tty_lock.lock_count); > tty_lock.lock_count++; > return flags; > } > spin_lock(&tty_lock.lock); > got_lock: > WARN_ON(tty_lock.lock_owner); <etc...> I would change it to something like the following (without testing the code through a compiler or anything to see if it's valid): if (!(spin_trylock(&tty_lock.lock))){ if (tsk ==tty_lock.lock_owner){ WRAN_ON(!tty_lock.lcok_count); tty_lock.lock_count++; return flags; } } WARN_ON(tty_lock.lock_owner); <etc...> Am I wrong that the above would do the same thing without generating the sphagetti code that a goto would give you. Gotos are BAD, very very bad. Please note also that the two if statements above could probably even be combined further into one statement by using a short circuit && in the if. If I'm misinterpreting the original code, then forgive me.. I just saw a goto and gasped. There's always a better option than goto. -Rob ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 19:34 ` Rob Wilkens @ 2003-01-12 19:37 ` Rob Wilkens 2003-01-12 19:53 ` Tomas Szepe 2003-01-12 19:38 ` Linus Torvalds ` (6 subsequent siblings) 7 siblings, 1 reply; 173+ messages in thread From: Rob Wilkens @ 2003-01-12 19:37 UTC (permalink / raw) To: Linus Torvalds Cc: Christoph Hellwig, Greg KH, Alan Cox, William Lee Irwin III, Linux Kernel Mailing List Minor change to my original message below.. I left a line out of a code change suggestion. On Sun, 2003-01-12 at 14:34, Rob Wilkens wrote: > Linus, > > I'm REALLY opposed to the use of the word "goto" in any code where it's > not needed. OF course, I'm a linux kernel newbie, so I'm in no position > to comment > > Let me comment below the relevant code snippet below as to how I would > change it: > > On Sun, 2003-01-12 at 14:15, Linus Torvalds wrote: > > if (spin_trylock(&tty_lock.lock)) > > goto got_lock; > > if (tsk == tty_lock.lock_owner) { > > WARN_ON(!tty_lock.lock_count); > > tty_lock.lock_count++; > > return flags; > > } > > spin_lock(&tty_lock.lock); > > got_lock: > > WARN_ON(tty_lock.lock_owner); > <etc...> > > I would change it to something like the following (without testing the > code through a compiler or anything to see if it's valid): > > if (!(spin_trylock(&tty_lock.lock))){ > if (tsk ==tty_lock.lock_owner){ > WRAN_ON(!tty_lock.lcok_count); > tty_lock.lock_count++; > return flags; > } > } oops - Yes, I forgot to add one line here (my point remains the same: spin_lock(&tty_lock.lock); > WARN_ON(tty_lock.lock_owner); > <etc...> > > Am I wrong that the above would do the same thing without generating the > sphagetti code that a goto would give you. Gotos are BAD, very very > bad. Please note also that the two if statements above could probably > even be combined further into one statement by using a short circuit && > in the if. > > If I'm misinterpreting the original code, then forgive me.. I just saw > a goto and gasped. There's always a better option than goto. > > -Rob ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 19:37 ` Rob Wilkens @ 2003-01-12 19:53 ` Tomas Szepe 2003-01-12 20:03 ` Rob Wilkens ` (4 more replies) 0 siblings, 5 replies; 173+ messages in thread From: Tomas Szepe @ 2003-01-12 19:53 UTC (permalink / raw) To: Rob Wilkens Cc: Christoph Hellwig, Greg KH, Alan Cox, William Lee Irwin III, Linux Kernel Mailing List > [robw@optonline.net] > > Am I wrong that the above would do the same thing without generating the > sphagetti code that a goto would give you. Gotos are BAD, very very > bad. Whom do I pay to have this annoying clueless asshole shot? OH MY GOD, I really can't take any more. -- Tomas Szepe <szepe@pinerecords.com> ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 19:53 ` Tomas Szepe @ 2003-01-12 20:03 ` Rob Wilkens 2003-01-13 15:43 ` Terje Eggestad 2003-01-12 20:44 ` Alan Cox ` (3 subsequent siblings) 4 siblings, 1 reply; 173+ messages in thread From: Rob Wilkens @ 2003-01-12 20:03 UTC (permalink / raw) To: Tomas Szepe Cc: Christoph Hellwig, Greg KH, Alan Cox, William Lee Irwin III, Linux Kernel Mailing List On Sun, 2003-01-12 at 14:53, Tomas Szepe wrote: > > [robw@optonline.net] > > > > Am I wrong that the above would do the same thing without generating the > > sphagetti code that a goto would give you. Gotos are BAD, very very > > bad. > > Whom do I pay to have this annoying clueless asshole shot? > OH MY GOD, I really can't take any more. Mail filters are a wonderful thing, use them on me and you want have to have me shot. We'll both be happier in the end. What exactly is it that you can't take? I made a minor suggestion in the above message, very minor, and only a suggestion -- one that was free to be ignorred. There are over 300 messages a day on this list, why do the few ones from _me_ bother you. -Rob ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 20:03 ` Rob Wilkens @ 2003-01-13 15:43 ` Terje Eggestad 2003-01-13 15:49 ` Jens Axboe 0 siblings, 1 reply; 173+ messages in thread From: Terje Eggestad @ 2003-01-13 15:43 UTC (permalink / raw) To: robw; +Cc: Linux Kernel Mailing List 1) newbies has made the very same "minor" suggestion before; and had their heads summarily chopped of. 2) It's not a minor suggestion. 3) and more to the point, you proved your selv why it's a dumb idea to remove them, when you had to correct you own code 2 minutes after you posted it. -------------------- begin quote --------------------------------- On Sun, 2003-01-12 at 14:34, Rob Wilkens wrote: > I would change it to something like the following (without testing the > code through a compiler or anything to see if it's valid): > > if (!(spin_trylock(&tty_lock.lock))){ > if (tsk ==tty_lock.lock_owner){ > WRAN_ON(!tty_lock.lcok_count); > tty_lock.lock_count++; > return flags; > } > } oops - Yes, I forgot to add one line here (my point remains the same: spin_lock(&tty_lock.lock); > WARN_ON(tty_lock.lock_owner); > <etc...> > -------------------- end quote --------------------------------- OF all the reasons to use goto, spinlocks are alone reason enough. By omitting the very little line you did you created a race condition. Now I'm assuming that you know what a race condition is. IF YOU DON'T: DO NOT ASK! L-O-O-K I-T U-P !!!! Now since races are the worst kind of problems, in that they causes seemingly random data corruption, or of you forget a spinunlock you get a hung machine, minimize them is of paramount importance. Considering that doing kernel development is hard enough, new development is almost always done on uni processors kernels that do only one thing at the time. Then when you base logic is OK, you move to a SMP, which means (adding and) debugging you spin locks. Considering that fucking up spin locks are prone to corrupting your machine, one very simple trick to makeing fewer mistakes to to have one, and only one, unlock for every lock. In order to achive that you write your function to have one entry point (which all C functions have) and one exit point, thus one and only one return. In order to do that you can either concoct a set of if-then-else-orelse logic that is incomprehensible, or you use goto! Now you may look at Linus's code you buggified, and point out that the lock and unlock are not in the same function, then read Linus's original post CAREFULLY! And UNDERSTAND how these functions are used. On søn, 2003-01-12 at 21:03, Rob Wilkens wrote: > On Sun, 2003-01-12 at 14:53, Tomas Szepe wrote: > > > [robw@optonline.net] > > > > > > Am I wrong that the above would do the same thing without generating the > > > sphagetti code that a goto would give you. Gotos are BAD, very very > > > bad. > > > > Whom do I pay to have this annoying clueless asshole shot? > > OH MY GOD, I really can't take any more. > > Mail filters are a wonderful thing, use them on me and you want have to > have me shot. We'll both be happier in the end. > > What exactly is it that you can't take? I made a minor suggestion in > the above message, very minor, and only a suggestion -- one that was > free to be ignorred. There are over 300 messages a day on this list, > why do the few ones from _me_ bother you. > > -Rob > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- _________________________________________________________________________ Terje Eggestad mailto:terje.eggestad@scali.no Scali Scalable Linux Systems http://www.scali.com Olaf Helsets Vei 6 tel: +47 22 62 89 61 (OFFICE) P.O.Box 150, Oppsal +47 975 31 574 (MOBILE) N-0619 Oslo fax: +47 22 62 89 51 NORWAY _________________________________________________________________________ ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 15:43 ` Terje Eggestad @ 2003-01-13 15:49 ` Jens Axboe 2003-01-13 16:25 ` Terje Eggestad 0 siblings, 1 reply; 173+ messages in thread From: Jens Axboe @ 2003-01-13 15:49 UTC (permalink / raw) To: terje.eggestad; +Cc: Linux Kernel Mailing List On Mon, Jan 13 2003, Terje Eggestad wrote: > Considering that doing kernel development is hard enough, new > development is almost always done on uni processors kernels that do only > one thing at the time. Then when you base logic is OK, you move to a > SMP, which means (adding and) debugging you spin locks. Goto's aside, I find the above extremely bad advise. You should _always_ develop with smp and for smp from the very start, or you will most likely not get it right later on. With preempt, this becomes even more important. > Considering that fucking up spin locks are prone to corrupting your > machine, one very simple trick to makeing fewer mistakes to to have one, > and only one, unlock for every lock. Taking a spin lock twice will hard lock the machine, however on smp you will typically have the luxury of an nmi watchdog which will help you solve this quickly. Double unlock will oops immediately if you run with spin lock debugging (you probably should, if you are developing kernel code). -- Jens Axboe ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 15:49 ` Jens Axboe @ 2003-01-13 16:25 ` Terje Eggestad 2003-01-13 16:26 ` Jens Axboe 0 siblings, 1 reply; 173+ messages in thread From: Terje Eggestad @ 2003-01-13 16:25 UTC (permalink / raw) To: Jens Axboe; +Cc: Linux Kernel Mailing List On man, 2003-01-13 at 16:49, Jens Axboe wrote: > On Mon, Jan 13 2003, Terje Eggestad wrote: > > Considering that doing kernel development is hard enough, new > > development is almost always done on uni processors kernels that do only > > one thing at the time. Then when you base logic is OK, you move to a > > SMP, which means (adding and) debugging you spin locks. > > Goto's aside, I find the above extremely bad advise. You should _always_ > develop with smp and for smp from the very start, or you will most > likely not get it right later on. With preempt, this becomes even more > important. You should, and I do, *design* with smp in mind, and I throw in smplock/unlonk as I go, but I tend to make first runs on a UP. I see your point on preemt, though. You do first runs on SMP? > > Considering that fucking up spin locks are prone to corrupting your > > machine, one very simple trick to makeing fewer mistakes to to have one, > > and only one, unlock for every lock. > > Taking a spin lock twice will hard lock the machine, however on smp you > will typically have the luxury of an nmi watchdog which will help you > solve this quickly. Double unlock will oops immediately if you run with > spin lock debugging (you probably should, if you are developing kernel > code). I have the console on a serial port, and a terminal server. With kdb, you can enter the kernel i kdb even when deadlocked. TJ -- _________________________________________________________________________ Terje Eggestad mailto:terje.eggestad@scali.no Scali Scalable Linux Systems http://www.scali.com Olaf Helsets Vei 6 tel: +47 22 62 89 61 (OFFICE) P.O.Box 150, Oppsal +47 975 31 574 (MOBILE) N-0619 Oslo fax: +47 22 62 89 51 NORWAY _________________________________________________________________________ ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 16:25 ` Terje Eggestad @ 2003-01-13 16:26 ` Jens Axboe 2003-01-13 16:41 ` Terje Eggestad 0 siblings, 1 reply; 173+ messages in thread From: Jens Axboe @ 2003-01-13 16:26 UTC (permalink / raw) To: Terje Eggestad; +Cc: Linux Kernel Mailing List On Mon, Jan 13 2003, Terje Eggestad wrote: > On man, 2003-01-13 at 16:49, Jens Axboe wrote: > > On Mon, Jan 13 2003, Terje Eggestad wrote: > > > Considering that doing kernel development is hard enough, new > > > development is almost always done on uni processors kernels that do only > > > one thing at the time. Then when you base logic is OK, you move to a > > > SMP, which means (adding and) debugging you spin locks. > > > > Goto's aside, I find the above extremely bad advise. You should _always_ > > develop with smp and for smp from the very start, or you will most > > likely not get it right later on. With preempt, this becomes even more > > important. > > You should, and I do, *design* with smp in mind, and I throw in > smplock/unlonk as I go, but I tend to make first runs on a UP. > > I see your point on preemt, though. > You do first runs on SMP? Always, if for nothing else than the benefit of a better debugging environment. > > > Considering that fucking up spin locks are prone to corrupting your > > > machine, one very simple trick to makeing fewer mistakes to to have one, > > > and only one, unlock for every lock. > > > > Taking a spin lock twice will hard lock the machine, however on smp you > > will typically have the luxury of an nmi watchdog which will help you > > solve this quickly. Double unlock will oops immediately if you run with > > spin lock debugging (you probably should, if you are developing kernel > > code). > > I have the console on a serial port, and a terminal server. With kdb, > you can enter the kernel i kdb even when deadlocked. Even if spinning with interrupt disabled? -- Jens Axboe ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 16:26 ` Jens Axboe @ 2003-01-13 16:41 ` Terje Eggestad 2003-01-13 16:43 ` Jens Axboe 0 siblings, 1 reply; 173+ messages in thread From: Terje Eggestad @ 2003-01-13 16:41 UTC (permalink / raw) To: Jens Axboe; +Cc: Linux Kernel Mailing List On man, 2003-01-13 at 17:26, Jens Axboe wrote: > On Mon, Jan 13 2003, Terje Eggestad wrote: > > On man, 2003-01-13 at 16:49, Jens Axboe wrote: > > > On Mon, Jan 13 2003, Terje Eggestad wrote: > > > > Considering that doing kernel development is hard enough, new > > > > development is almost always done on uni processors kernels that do only > > > > one thing at the time. Then when you base logic is OK, you move to a > > > > SMP, which means (adding and) debugging you spin locks. > > > > > > Goto's aside, I find the above extremely bad advise. You should _always_ > > > develop with smp and for smp from the very start, or you will most > > > likely not get it right later on. With preempt, this becomes even more > > > important. > > > > You should, and I do, *design* with smp in mind, and I throw in > > smplock/unlonk as I go, but I tend to make first runs on a UP. > > > > I see your point on preemt, though. > > You do first runs on SMP? > > Always, if for nothing else than the benefit of a better debugging > environment. > > > > > Considering that fucking up spin locks are prone to corrupting your > > > > machine, one very simple trick to makeing fewer mistakes to to have one, > > > > and only one, unlock for every lock. > > > > > > Taking a spin lock twice will hard lock the machine, however on smp you > > > will typically have the luxury of an nmi watchdog which will help you > > > solve this quickly. Double unlock will oops immediately if you run with > > > spin lock debugging (you probably should, if you are developing kernel > > > code). > > > > I have the console on a serial port, and a terminal server. With kdb, > > you can enter the kernel i kdb even when deadlocked. > > Even if spinning with interrupt disabled? Haven't painted myself into that corner yet. Doubt it, very much. -- _________________________________________________________________________ Terje Eggestad mailto:terje.eggestad@scali.no Scali Scalable Linux Systems http://www.scali.com Olaf Helsets Vei 6 tel: +47 22 62 89 61 (OFFICE) P.O.Box 150, Oppsal +47 975 31 574 (MOBILE) N-0619 Oslo fax: +47 22 62 89 51 NORWAY _________________________________________________________________________ ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 16:41 ` Terje Eggestad @ 2003-01-13 16:43 ` Jens Axboe 2003-01-13 17:00 ` Zwane Mwaikambo 0 siblings, 1 reply; 173+ messages in thread From: Jens Axboe @ 2003-01-13 16:43 UTC (permalink / raw) To: Terje Eggestad; +Cc: Linux Kernel Mailing List On Mon, Jan 13 2003, Terje Eggestad wrote: > > > I have the console on a serial port, and a terminal server. With kdb, > > > you can enter the kernel i kdb even when deadlocked. > > > > Even if spinning with interrupt disabled? > > Haven't painted myself into that corner yet. Doubt it, very much. These are the nasty hangs, total lockup and no info at all if it wasn't for the nmi watchdog triggering. That alone is reason enough for me :-) -- Jens Axboe ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 16:43 ` Jens Axboe @ 2003-01-13 17:00 ` Zwane Mwaikambo 2003-01-13 18:48 ` Jens Axboe 0 siblings, 1 reply; 173+ messages in thread From: Zwane Mwaikambo @ 2003-01-13 17:00 UTC (permalink / raw) To: Jens Axboe; +Cc: Terje Eggestad, Linux Kernel Mailing List On Mon, 13 Jan 2003, Jens Axboe wrote: > On Mon, Jan 13 2003, Terje Eggestad wrote: > > > > I have the console on a serial port, and a terminal server. With kdb, > > > > you can enter the kernel i kdb even when deadlocked. > > > > > > Even if spinning with interrupt disabled? > > > > Haven't painted myself into that corner yet. Doubt it, very much. > > These are the nasty hangs, total lockup and no info at all if it wasn't > for the nmi watchdog triggering. That alone is reason enough for me :-) It uses NMI's to break into the debugger, so it would also work with interrupts disabled and spinning on a lock, the same is also true for kgdb. Zwane -- function.linuxpower.ca ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 17:00 ` Zwane Mwaikambo @ 2003-01-13 18:48 ` Jens Axboe 2003-01-13 22:14 ` Keith Owens 2003-01-13 22:49 ` Zwane Mwaikambo 0 siblings, 2 replies; 173+ messages in thread From: Jens Axboe @ 2003-01-13 18:48 UTC (permalink / raw) To: Zwane Mwaikambo; +Cc: Terje Eggestad, Linux Kernel Mailing List On Mon, Jan 13 2003, Zwane Mwaikambo wrote: > On Mon, 13 Jan 2003, Jens Axboe wrote: > > > On Mon, Jan 13 2003, Terje Eggestad wrote: > > > > > I have the console on a serial port, and a terminal server. With kdb, > > > > > you can enter the kernel i kdb even when deadlocked. > > > > > > > > Even if spinning with interrupt disabled? > > > > > > Haven't painted myself into that corner yet. Doubt it, very much. > > > > These are the nasty hangs, total lockup and no info at all if it wasn't > > for the nmi watchdog triggering. That alone is reason enough for me :-) > > It uses NMI's to break into the debugger, so it would also work with > interrupts disabled and spinning on a lock, the same is also true for > kgdb. But still requiring up-apic, or smp with apic, right? -- Jens Axboe ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 18:48 ` Jens Axboe @ 2003-01-13 22:14 ` Keith Owens 2003-01-13 22:42 ` John Levon 2003-01-13 22:49 ` Zwane Mwaikambo 1 sibling, 1 reply; 173+ messages in thread From: Keith Owens @ 2003-01-13 22:14 UTC (permalink / raw) To: Jens Axboe; +Cc: Zwane Mwaikambo, Linux Kernel Mailing List On Mon, 13 Jan 2003 19:48:31 +0100, Jens Axboe <axboe@suse.de> wrote: >On Mon, Jan 13 2003, Zwane Mwaikambo wrote: >> It uses NMI's to break into the debugger, so it would also work with >> interrupts disabled and spinning on a lock, the same is also true for >> kgdb. > >But still requiring up-apic, or smp with apic, right? nmi_watchdog=2 - uses performance counters, not apic. ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 22:14 ` Keith Owens @ 2003-01-13 22:42 ` John Levon 0 siblings, 0 replies; 173+ messages in thread From: John Levon @ 2003-01-13 22:42 UTC (permalink / raw) To: Keith Owens; +Cc: Jens Axboe, Zwane Mwaikambo, Linux Kernel Mailing List On Tue, Jan 14, 2003 at 09:14:52AM +1100, Keith Owens wrote: > >But still requiring up-apic, or smp with apic, right? > > nmi_watchdog=2 - uses performance counters, not apic. which requires a local APIC to set up NMI delivery mode like Jens said regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over. ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 18:48 ` Jens Axboe 2003-01-13 22:14 ` Keith Owens @ 2003-01-13 22:49 ` Zwane Mwaikambo 2003-01-13 23:32 ` Valdis.Kletnieks 1 sibling, 1 reply; 173+ messages in thread From: Zwane Mwaikambo @ 2003-01-13 22:49 UTC (permalink / raw) To: Jens Axboe; +Cc: Terje Eggestad, Linux Kernel Mailing List On Mon, 13 Jan 2003, Jens Axboe wrote: > > It uses NMI's to break into the debugger, so it would also work with > > interrupts disabled and spinning on a lock, the same is also true for > > kgdb. > > But still requiring up-apic, or smp with apic, right? Well UP with Local APIC will suffice. So that works on a lot of i686 machines. Zwane -- function.linuxpower.ca ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 22:49 ` Zwane Mwaikambo @ 2003-01-13 23:32 ` Valdis.Kletnieks 2003-01-13 23:43 ` Zwane Mwaikambo 0 siblings, 1 reply; 173+ messages in thread From: Valdis.Kletnieks @ 2003-01-13 23:32 UTC (permalink / raw) To: Zwane Mwaikambo; +Cc: Linux Kernel Mailing List [-- Attachment #1: Type: text/plain, Size: 525 bytes --] On Mon, 13 Jan 2003 17:49:12 EST, Zwane Mwaikambo said: > On Mon, 13 Jan 2003, Jens Axboe wrote: > > > > It uses NMI's to break into the debugger, so it would also work with > > > interrupts disabled and spinning on a lock, the same is also true for > > > kgdb. > > > > But still requiring up-apic, or smp with apic, right? > > Well UP with Local APIC will suffice. So that works on a lot of i686 > machines. This mean those of us that have a 'local_apic_kills_bios' flag in dmi_scan.c are still out of luck, correct? [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 23:32 ` Valdis.Kletnieks @ 2003-01-13 23:43 ` Zwane Mwaikambo 0 siblings, 0 replies; 173+ messages in thread From: Zwane Mwaikambo @ 2003-01-13 23:43 UTC (permalink / raw) To: Valdis.Kletnieks; +Cc: Linux Kernel Mailing List On Mon, 13 Jan 2003 Valdis.Kletnieks@vt.edu wrote: > This mean those of us that have a 'local_apic_kills_bios' flag in dmi_scan.c > are still out of luck, correct? Yep, blacklisted systems still won't work. Zwane -- function.linuxpower.ca ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 19:53 ` Tomas Szepe 2003-01-12 20:03 ` Rob Wilkens @ 2003-01-12 20:44 ` Alan Cox 2003-01-12 20:45 ` William Lee Irwin III ` (2 subsequent siblings) 4 siblings, 0 replies; 173+ messages in thread From: Alan Cox @ 2003-01-12 20:44 UTC (permalink / raw) To: Tomas Szepe Cc: Rob Wilkens, Christoph Hellwig, Greg KH, William Lee Irwin III, Linux Kernel Mailing List On Sun, 2003-01-12 at 19:53, Tomas Szepe wrote: > > [robw@optonline.net] > > > > Am I wrong that the above would do the same thing without generating the > > sphagetti code that a goto would give you. Gotos are BAD, very very > > bad. > > Whom do I pay to have this annoying clueless asshole shot? > OH MY GOD, I really can't take any more. In evolution its Tools->Create filter from message->Filter on sender Add action Move to folder QUAINT and then just read it when drunk ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 19:53 ` Tomas Szepe 2003-01-12 20:03 ` Rob Wilkens 2003-01-12 20:44 ` Alan Cox @ 2003-01-12 20:45 ` William Lee Irwin III 2003-01-13 13:14 ` Bernd Schmidt 2003-01-12 21:22 ` David Woodhouse 2003-01-18 13:04 ` Folkert van Heusden 4 siblings, 1 reply; 173+ messages in thread From: William Lee Irwin III @ 2003-01-12 20:45 UTC (permalink / raw) To: Tomas Szepe Cc: Rob Wilkens, Christoph Hellwig, Greg KH, Alan Cox, Linux Kernel Mailing List [robw@optonline.net] >> Am I wrong that the above would do the same thing without generating the >> sphagetti code that a goto would give you. Gotos are BAD, very very >> bad. On Sun, Jan 12, 2003 at 08:53:47PM +0100, Tomas Szepe wrote: > Whom do I pay to have this annoying clueless asshole shot? > OH MY GOD, I really can't take any more. >From the looks of it you forgot to procmail the idiot to /dev/null There are a lot more where he came from; you can't get rid of them all, it'd be genocide. procmail and get it over with. It's been a sad fact of life since they let those AOL and compuserve FPOS's on the net. Bill ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 20:45 ` William Lee Irwin III @ 2003-01-13 13:14 ` Bernd Schmidt 0 siblings, 0 replies; 173+ messages in thread From: Bernd Schmidt @ 2003-01-13 13:14 UTC (permalink / raw) To: William Lee Irwin III; +Cc: Linux Kernel Mailing List On Sun, 12 Jan 2003, William Lee Irwin III wrote: > >From the looks of it you forgot to procmail the idiot to /dev/null > > There are a lot more where he came from; you can't get rid of them > all, it'd be genocide. procmail and get it over with. It's been a sad > fact of life since they let those AOL and compuserve FPOS's on the net. I find linux-kernel works best if you read it with a positive list in .procmailrc rather than using it as a killfile. This would work even better if y'all didn't feed the trolls. Bernd ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 19:53 ` Tomas Szepe ` (2 preceding siblings ...) 2003-01-12 20:45 ` William Lee Irwin III @ 2003-01-12 21:22 ` David Woodhouse 2003-01-18 13:04 ` Folkert van Heusden 4 siblings, 0 replies; 173+ messages in thread From: David Woodhouse @ 2003-01-12 21:22 UTC (permalink / raw) To: Alan Cox Cc: Tomas Szepe, Rob Wilkens, Christoph Hellwig, Greg KH, William Lee Irwin III, Linux Kernel Mailing List alan@lxorguk.ukuu.org.uk said: > In evolution its > Tools->Create filter from message->Filter on sender > Add action > Move to folder QUAINT > and then just read it when drunk That's fine for this particular troll, but some of the more well-known trolls here are so good at what they do that you sometimes have to read their messages while sober -- the errors can be subtle and well-hidden. So much so, sometimes, that I suspect it's done on purpose. Besides, filtering in the MUA is blatantly the wrong place to do it. The MTA (or MDA) should be doing the filtering.¹ -- dwmw2 ¹ Yes, I'm bored of the other off-topic flames :) ^ permalink raw reply [flat|nested] 173+ messages in thread
* RE: any chance of 2.6.0-test*? 2003-01-12 19:53 ` Tomas Szepe ` (3 preceding siblings ...) 2003-01-12 21:22 ` David Woodhouse @ 2003-01-18 13:04 ` Folkert van Heusden 4 siblings, 0 replies; 173+ messages in thread From: Folkert van Heusden @ 2003-01-18 13:04 UTC (permalink / raw) To: 'Tomas Szepe', 'Rob Wilkens' Cc: 'Christoph Hellwig', 'Linux Kernel Mailing List' > Am I wrong that the above would do the same thing without generating the > sphagetti code that a goto would give you. Gotos are BAD, very very > bad. TS> Whom do I pay to have this annoying clueless asshole shot? TS> OH MY GOD, I really can't take any more. Well well well, is that how we act these days if we see something we don't like? Anyway, I totally agree with Rob: if the code can be written without a goto and produce the same efficient assembly (or better, see Robs change) it should be written without it. goto's are for lazy people ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 19:34 ` Rob Wilkens 2003-01-12 19:37 ` Rob Wilkens @ 2003-01-12 19:38 ` Linus Torvalds 2003-01-12 19:59 ` Rob Wilkens 2003-01-12 19:41 ` Christoph Hellwig ` (5 subsequent siblings) 7 siblings, 1 reply; 173+ messages in thread From: Linus Torvalds @ 2003-01-12 19:38 UTC (permalink / raw) To: Rob Wilkens Cc: Christoph Hellwig, Greg KH, Alan Cox, William Lee Irwin III, Linux Kernel Mailing List On Sun, 12 Jan 2003, Rob Wilkens wrote: > > I'm REALLY opposed to the use of the word "goto" in any code where it's > not needed. I think goto's are fine, and they are often more readable than large amounts of indentation. That's _especially_ true if the code flow isn't actually naturally indented (in this case it is, so I don't think using goto is in any way _clearer_ than not, but in general goto's can be quite good for readability). Of course, in stupid languages like Pascal, where labels cannot be descriptive, goto's can be bad. But that's not the fault of the goto, that's the braindamage of the language designer. Linus ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 19:38 ` Linus Torvalds @ 2003-01-12 19:59 ` Rob Wilkens 2003-01-12 20:18 ` Valdis.Kletnieks ` (5 more replies) 0 siblings, 6 replies; 173+ messages in thread From: Rob Wilkens @ 2003-01-12 19:59 UTC (permalink / raw) To: Linus Torvalds Cc: Christoph Hellwig, Greg KH, Alan Cox, William Lee Irwin III, Linux Kernel Mailing List On Sun, 2003-01-12 at 14:38, Linus Torvalds wrote: > I think goto's are fine You're a relatively succesful guy, so I guess I shouldn't argue with your style. However, I have always been taught, and have always believed that "goto"s are inherently evil. They are the creators of spaghetti code (you start reading through the code to understand it (months or years after its written), and suddenly you jump to somewhere totally unrelated, and then jump somewhere else backwards, and it all gets ugly quickly). This makes later debugging of code total hell. Would it be so terrible for you to change the code you had there to _not_ use a goto and instead use something similar to what I suggested? Never mind the philosophical arguments, I'm just talking good coding style for a relatively small piece of code. If you want, but comments in your code to meaningfully describe what's happening instead of goto labels. In general, if you can structure your code properly, you should never need a goto, and if you don't need a goto you shouldn't use it. It's just "common sense" as I've always been taught. Unless you're intentionally trying to write code that's harder for others to read. -Rob ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 19:59 ` Rob Wilkens @ 2003-01-12 20:18 ` Valdis.Kletnieks 2003-01-12 20:23 ` yodaiken ` (5 more replies) 2003-01-12 20:20 ` David Ford ` (4 subsequent siblings) 5 siblings, 6 replies; 173+ messages in thread From: Valdis.Kletnieks @ 2003-01-12 20:18 UTC (permalink / raw) To: robw; +Cc: Linux Kernel Mailing List [-- Attachment #1: Type: text/plain, Size: 928 bytes --] On Sun, 12 Jan 2003 14:59:57 EST, Rob Wilkens said: > In general, if you can structure your code properly, you should never > need a goto, and if you don't need a goto you shouldn't use it. It's > just "common sense" as I've always been taught. Unless you're > intentionally trying to write code that's harder for others to read. Now, it's provable you never *NEED* a goto. On the other hand, *judicious* use of goto can prevent code that is so cluttered with stuff of the form: if(...) { ... die_flag = 1; if (!die _flag) {... Pretty soon, you have die_1_flag, die_2_flag, die_3_flag and so on, rather than 3 or 4 "goto bail_now;". The real problem is that C doesn't have a good multi-level "break" construct. On the other hand, I don't know of any language that has a good one - some allow "break 3;" to break 3 levels- but that's still bad because you get screwed if somebody adds an 'if' clause.... [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 20:18 ` Valdis.Kletnieks @ 2003-01-12 20:23 ` yodaiken 2003-01-12 20:26 ` Tomas Szepe ` (4 subsequent siblings) 5 siblings, 0 replies; 173+ messages in thread From: yodaiken @ 2003-01-12 20:23 UTC (permalink / raw) To: Valdis.Kletnieks; +Cc: robw, Linux Kernel Mailing List On Sun, Jan 12, 2003 at 03:18:38PM -0500, Valdis.Kletnieks@vt.edu wrote: > On Sun, 12 Jan 2003 14:59:57 EST, Rob Wilkens said: > > > In general, if you can structure your code properly, you should never > > need a goto, and if you don't need a goto you shouldn't use it. It's > > just "common sense" as I've always been taught. Unless you're > > intentionally trying to write code that's harder for others to read. > > Now, it's provable you never *NEED* a goto. On the other hand, *judicious* > use of goto can prevent code that is so cluttered with stuff of the form: > > if(...) { > ... > die_flag = 1; > if (!die _flag) {... > > Pretty soon, you have die_1_flag, die_2_flag, die_3_flag and so on, > rather than 3 or 4 "goto bail_now;". > > The real problem is that C doesn't have a good multi-level "break" construct. longjump. Used with good effect in the plan9 code. Probably takes more coordination than is possible in Linux and has marginal benefit, but it looks nice. -- --------------------------------------------------------- Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com 1+ 505 838 9109 ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 20:18 ` Valdis.Kletnieks 2003-01-12 20:23 ` yodaiken @ 2003-01-12 20:26 ` Tomas Szepe 2003-01-12 20:32 ` Sean Neakums ` (3 subsequent siblings) 5 siblings, 0 replies; 173+ messages in thread From: Tomas Szepe @ 2003-01-12 20:26 UTC (permalink / raw) To: Valdis.Kletnieks; +Cc: linux-kernel > [Valdis.Kletnieks@vt.edu] > > The real problem is that C doesn't have a good multi-level "break" construct. > On the other hand, I don't know of any language that has a good one - some > allow "break 3;" to break 3 levels- but that's still bad because you get > screwed if somebody adds an 'if' clause.... Not necessarily. A good multilevel break/continue implementation will only work on loop blocks, not conditionals. -- Tomas Szepe <szepe@pinerecords.com> ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 20:18 ` Valdis.Kletnieks 2003-01-12 20:23 ` yodaiken 2003-01-12 20:26 ` Tomas Szepe @ 2003-01-12 20:32 ` Sean Neakums 2003-01-12 20:51 ` Valdis.Kletnieks 2003-01-13 0:54 ` Randy Dunlap 2003-01-12 20:46 ` Kevin Puetz ` (2 subsequent siblings) 5 siblings, 2 replies; 173+ messages in thread From: Sean Neakums @ 2003-01-12 20:32 UTC (permalink / raw) To: linux-kernel commence Valdis.Kletnieks@vt.edu quotation: > The real problem is that C doesn't have a good multi-level "break" > construct. On the other hand, I don't know of any language that has > a good one - some allow "break 3;" to break 3 levels- but that's > still bad because you get screwed if somebody adds an 'if' > clause.... Perl's facility for labelling blocks and jumping to the beginning or end with 'next' and 'last' may be close to what you want, but I don't know if it's ever been implemented in a language one could sensibly use to write a kernel. -- / | [|] Sean Neakums | Questions are a burden to others; [|] <sneakums@zork.net> | answers a prison for oneself. \ | ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 20:32 ` Sean Neakums @ 2003-01-12 20:51 ` Valdis.Kletnieks 2003-01-13 0:54 ` Randy Dunlap 1 sibling, 0 replies; 173+ messages in thread From: Valdis.Kletnieks @ 2003-01-12 20:51 UTC (permalink / raw) To: Sean Neakums; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 777 bytes --] On Sun, 12 Jan 2003 20:32:01 GMT, Sean Neakums <sneakums@zork.net> said: > commence Valdis.Kletnieks@vt.edu quotation: > > > The real problem is that C doesn't have a good multi-level "break" > > construct. On the other hand, I don't know of any language that has > > a good one - some allow "break 3;" to break 3 levels- but that's > > still bad because you get screwed if somebody adds an 'if' > > clause.... > > Perl's facility for labelling blocks and jumping to the beginning or > end with 'next' and 'last' may be close to what you want, but I don't > know if it's ever been implemented in a language one could sensibly > use to write a kernel. Hmm.. I'm not a Perl wizard.. <reads the docs> Yeah, that's what I meant, and no, that's not a sane kernel language. ;) [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 20:32 ` Sean Neakums 2003-01-12 20:51 ` Valdis.Kletnieks @ 2003-01-13 0:54 ` Randy Dunlap 1 sibling, 0 replies; 173+ messages in thread From: Randy Dunlap @ 2003-01-13 0:54 UTC (permalink / raw) To: sneakums; +Cc: linux-kernel > commence Valdis.Kletnieks@vt.edu quotation: > >> The real problem is that C doesn't have a good multi-level "break" >> construct. On the other hand, I don't know of any language that has a >> good one - some allow "break 3;" to break 3 levels- but that's still bad >> because you get screwed if somebody adds an 'if' >> clause.... > > Perl's facility for labelling blocks and jumping to the beginning or end > with 'next' and 'last' may be close to what you want, but I don't know if > it's ever been implemented in a language one could sensibly use to write a > kernel. Yes, Burroughs (who?) implemented it in System Development Language (SDL) more than 20 years ago. Worked very well. ~Randy (I hope I don't find more of this thread to reply to. :( ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 20:18 ` Valdis.Kletnieks ` (2 preceding siblings ...) 2003-01-12 20:32 ` Sean Neakums @ 2003-01-12 20:46 ` Kevin Puetz 2003-01-13 0:48 ` Randy Dunlap 2003-01-18 13:07 ` Folkert van Heusden 5 siblings, 0 replies; 173+ messages in thread From: Kevin Puetz @ 2003-01-12 20:46 UTC (permalink / raw) To: linux-kernel Valdis.Kletnieks@vt.edu wrote: > On Sun, 12 Jan 2003 14:59:57 EST, Rob Wilkens said: > >> In general, if you can structure your code properly, you should never >> need a goto, and if you don't need a goto you shouldn't use it. It's >> just "common sense" as I've always been taught. Unless you're >> intentionally trying to write code that's harder for others to read. > > Now, it's provable you never *NEED* a goto. On the other hand, > *judicious* use of goto can prevent code that is so cluttered with stuff > of the form: > > if(...) { > ... > die_flag = 1; > if (!die _flag) {... > > Pretty soon, you have die_1_flag, die_2_flag, die_3_flag and so on, > rather than 3 or 4 "goto bail_now;". > > The real problem is that C doesn't have a good multi-level "break" > construct. On the other hand, I don't know of any language that has a good > one - some allow "break 3;" to break 3 levels- but that's still bad > because you get screwed if somebody adds an 'if' clause.... perl has a pretty nice one... you can label each construct to which break is applicable (ie, loop or whatever) then say "break foo" to escape that struture (and any others you happen to be inside. ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 20:18 ` Valdis.Kletnieks ` (3 preceding siblings ...) 2003-01-12 20:46 ` Kevin Puetz @ 2003-01-13 0:48 ` Randy Dunlap 2003-01-18 13:07 ` Folkert van Heusden 5 siblings, 0 replies; 173+ messages in thread From: Randy Dunlap @ 2003-01-13 0:48 UTC (permalink / raw) To: Valdis.Kletnieks; +Cc: robw, linux-kernel > On Sun, 12 Jan 2003 14:59:57 EST, Rob Wilkens said: > >> In general, if you can structure your code properly, you should never need >> a goto, and if you don't need a goto you shouldn't use it. It's just >> "common sense" as I've always been taught. Unless you're >> intentionally trying to write code that's harder for others to read. > > Now, it's provable you never *NEED* a goto. On the other hand, *judicious* > use of goto can prevent code that is so cluttered with stuff of the form: > > if(...) { > ... > die_flag = 1; > if (!die _flag) {... > > Pretty soon, you have die_1_flag, die_2_flag, die_3_flag and so on, rather > than 3 or 4 "goto bail_now;". Right. > The real problem is that C doesn't have a good multi-level "break" > construct. On the other hand, I don't know of any language that has a good > one - some allow "break 3;" to break 3 levels- but that's still bad because > you get screwed if somebody adds an 'if' clause.... The one that I used in a previous life was like so. No "while" or "for" constructs, only "do thisloop forever" with conditionals all being explicitly coded inside the loop(s). All based on: do [loopname] [forever]; {block}; end [loopname]; with {block} possibly containing "undo [loopname]". An unnamed undo just terminates the innermost loop. Named undo's can be used to terminate any loop level. ~Randy ^ permalink raw reply [flat|nested] 173+ messages in thread
* RE: any chance of 2.6.0-test*? 2003-01-12 20:18 ` Valdis.Kletnieks ` (4 preceding siblings ...) 2003-01-13 0:48 ` Randy Dunlap @ 2003-01-18 13:07 ` Folkert van Heusden 5 siblings, 0 replies; 173+ messages in thread From: Folkert van Heusden @ 2003-01-18 13:07 UTC (permalink / raw) To: Valdis.Kletnieks, robw; +Cc: 'Linux Kernel Mailing List' > Now, it's provable you never *NEED* a goto. On the other hand, *judicious* > use of goto can prevent code that is so cluttered with stuff of the form: > if(...) { > ... > die_flag = 1; > if (!die _flag) {... > > Pretty soon, you have die_1_flag, die_2_flag, die_3_flag and so on, > rather than 3 or 4 "goto bail_now;". There's always the construction: for(;;) { /* do something */ if (something_failed) break; /* do something */ if (something_failed) break; ... break; /* the final break */ } etc. ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 19:59 ` Rob Wilkens 2003-01-12 20:18 ` Valdis.Kletnieks @ 2003-01-12 20:20 ` David Ford 2003-01-12 20:22 ` Linus Torvalds ` (3 subsequent siblings) 5 siblings, 0 replies; 173+ messages in thread From: David Ford @ 2003-01-12 20:20 UTC (permalink / raw) To: robw, Linux Kernel Mailing List, Ben Ford -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gotos aren't the root of code evil. Poor design style is and poor preparation is the root of spaghetti code. Use the right tool for the job which includes 'goto'. Every teacher that I've met who has an objection to the use of gotos has been quite naive, often recommends avoiding pointers, frequently suggests you restrict your strings to 255 characters or less, etc, etc. The oddball extras vary from teacher to teacher, but the overall impression of the teacher makes me want to avoid them even with that 10 foot pole. It's not the fault of the student for being taught wrong, but it is the fault of the student for ignoring possibile variances of others. Particularly the "worldly wise"; people who actually write code for the real world v.s. lectures. David Rob Wilkens wrote: >On Sun, 2003-01-12 at 14:38, Linus Torvalds wrote: > > >>I think goto's are fine >> >> > >You're a relatively succesful guy, so I guess I shouldn't argue with >your style. > >However, I have always been taught, and have always believed that >"goto"s are inherently evil. They are the creators of spaghetti code >(you start reading through the code to understand it (months or years >after its written), and suddenly you jump to somewhere totally >unrelated, and then jump somewhere else backwards, and it all gets ugly >quickly). This makes later debugging of code total hell. > >Would it be so terrible for you to change the code you had there to >_not_ use a goto and instead use something similar to what I suggested? >Never mind the philosophical arguments, I'm just talking good coding >style for a relatively small piece of code. > >If you want, but comments in your code to meaningfully describe what's >happening instead of goto labels. > >In general, if you can structure your code properly, you should never >need a goto, and if you don't need a goto you shouldn't use it. It's >just "common sense" as I've always been taught. Unless you're >intentionally trying to write code that's harder for others to read. > >-Rob > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+Ic4P74cGT/9uvgsRAt1QAKCb7ryMMG5iBwTefYgDB7HLuDkRngCeNSq/ M/euGkdIdXpv6IZ1Rw9ikEo= =Yy9i -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 19:59 ` Rob Wilkens 2003-01-12 20:18 ` Valdis.Kletnieks 2003-01-12 20:20 ` David Ford @ 2003-01-12 20:22 ` Linus Torvalds 2003-01-12 20:33 ` Robert Love ` (2 more replies) 2003-01-12 21:29 ` Rik van Riel ` (2 subsequent siblings) 5 siblings, 3 replies; 173+ messages in thread From: Linus Torvalds @ 2003-01-12 20:22 UTC (permalink / raw) To: Rob Wilkens Cc: Christoph Hellwig, Greg KH, Alan Cox, William Lee Irwin III, Linux Kernel Mailing List On Sun, 12 Jan 2003, Rob Wilkens wrote: > > However, I have always been taught, and have always believed that > "goto"s are inherently evil. They are the creators of spaghetti code No, you've been brainwashed by CS people who thought that Niklaus Wirth actually knew what he was talking about. He didn't. He doesn't have a frigging clue. > (you start reading through the code to understand it (months or years > after its written), and suddenly you jump to somewhere totally > unrelated, and then jump somewhere else backwards, and it all gets ugly > quickly). This makes later debugging of code total hell. Any if-statement is a goto. As are all structured loops. Ans sometimes structure is good. When it's good, you should use it. And sometimes structure is _bad_, and gets into the way, and using a "goto" is just much clearer. For example, it is quite common to have conditionals THAT DO NOT NEST. In which case you have two possibilities - use goto, and be happy, since it doesn't enforce nesting This makes the code _more_ readable, since the code just does what the algorithm says it should do. - duplicate the code, and rewrite it in a nesting form so that you can use the structured jumps. This often makes the code much LESS readable, harder to maintain, and bigger. The Pascal language is a prime example of the latter problem. Because it doesn't have a "break" statement, loops in (traditional) Pascal end up often looking like total shit, because you have to add totally arbitrary logic to say "I'm done now". Linus ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 20:22 ` Linus Torvalds @ 2003-01-12 20:33 ` Robert Love 2003-01-12 20:33 ` Linus Torvalds 2003-01-12 20:48 ` Rob Wilkens 2003-01-13 3:30 ` yodaiken 2 siblings, 1 reply; 173+ messages in thread From: Robert Love @ 2003-01-12 20:33 UTC (permalink / raw) To: Linus Torvalds Cc: Rob Wilkens, Christoph Hellwig, Greg KH, Alan Cox, William Lee Irwin III, Linux Kernel Mailing List On Sun, 2003-01-12 at 15:22, Linus Torvalds wrote: > No, you've been brainwashed by CS people who thought that Niklaus > Wirth actually knew what he was talking about. He didn't. He > doesn't have a frigging clue. I thought Edsger Dijkstra coined the "gotos are evil" bit in his structured programming push? Nonetheless, they would both be wrong... Robert Love ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 20:33 ` Robert Love @ 2003-01-12 20:33 ` Linus Torvalds 2003-01-13 10:54 ` Horst von Brand 2003-01-13 11:09 ` Eric W. Biederman 0 siblings, 2 replies; 173+ messages in thread From: Linus Torvalds @ 2003-01-12 20:33 UTC (permalink / raw) To: Robert Love Cc: Rob Wilkens, Christoph Hellwig, Greg KH, Alan Cox, William Lee Irwin III, Linux Kernel Mailing List On 12 Jan 2003, Robert Love wrote: > On Sun, 2003-01-12 at 15:22, Linus Torvalds wrote: > > > No, you've been brainwashed by CS people who thought that Niklaus > > Wirth actually knew what he was talking about. He didn't. He > > doesn't have a frigging clue. > > I thought Edsger Dijkstra coined the "gotos are evil" bit in his > structured programming push? Yeah, he did, but he's dead, and we shouldn't talk ill of the dead. So these days I can only rant about Niklaus Wirth, who took the "structured programming" thing and enforced it in his languages (Pascal and Modula-2), and thus forced his evil on untold generations of poor CS students who had to learn langauges that weren't actually useful for real work. (Yeah, yeah, most _practical_ versions of Pascal ended up having all the stuff necessary to break structure, but as you may be able to tell, I was one of the unwashed masses who had to write in "standard Pascal" in my youth. I'm scarred for life). Linus ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 20:33 ` Linus Torvalds @ 2003-01-13 10:54 ` Horst von Brand 2003-01-13 11:09 ` Eric W. Biederman 1 sibling, 0 replies; 173+ messages in thread From: Horst von Brand @ 2003-01-13 10:54 UTC (permalink / raw) To: Linus Torvalds; +Cc: Linux Kernel Mailing List Linus Torvalds <torvalds@transmeta.com> said: > On 12 Jan 2003, Robert Love wrote: > > On Sun, 2003-01-12 at 15:22, Linus Torvalds wrote: > > > > > No, you've been brainwashed by CS people who thought that Niklaus > > > Wirth actually knew what he was talking about. He didn't. He > > > doesn't have a frigging clue. > > > > I thought Edsger Dijkstra coined the "gotos are evil" bit in his > > structured programming push? > Yeah, he did, but he's dead, and we shouldn't talk ill of the dead. So > these days I can only rant about Niklaus Wirth, who took the "structured > programming" thing and enforced it in his languages (Pascal and Modula-2), > and thus forced his evil on untold generations of poor CS students who had > to learn langauges that weren't actually useful for real work. You did not live through the horror that was FORTRAN IV, I learned programming in it (no structure except DO, a primitive for). Sure, Pascal strictures are overkill, but in a sense they were needed to implant a bit of structure into the mess that usually came before. > (Yeah, yeah, most _practical_ versions of Pascal ended up having all the > stuff necessary to break structure, but as you may be able to tell, I was > one of the unwashed masses who had to write in "standard Pascal" in my > youth. I'm scarred for life). And you do break structure only when necessary, so the dosis of Pascal did you some good after all ;-) -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 20:33 ` Linus Torvalds 2003-01-13 10:54 ` Horst von Brand @ 2003-01-13 11:09 ` Eric W. Biederman 2003-01-13 14:34 ` Terje Eggestad 2003-01-13 23:23 ` Bob Taylor 1 sibling, 2 replies; 173+ messages in thread From: Eric W. Biederman @ 2003-01-13 11:09 UTC (permalink / raw) To: Linus Torvalds Cc: Robert Love, Rob Wilkens, Christoph Hellwig, Greg KH, Alan Cox, William Lee Irwin III, Linux Kernel Mailing List Linus Torvalds <torvalds@transmeta.com> writes: > On 12 Jan 2003, Robert Love wrote: > > On Sun, 2003-01-12 at 15:22, Linus Torvalds wrote: > > > > > No, you've been brainwashed by CS people who thought that Niklaus > > > Wirth actually knew what he was talking about. He didn't. He > > > doesn't have a frigging clue. > > > > I thought Edsger Dijkstra coined the "gotos are evil" bit in his > > structured programming push? > Actually Edsger Dijkstra wrote a paper entitled "Goto considered Harmful" He never called them evil. And the title was more for shock value to grab peoples attention. For the beginners Dijkstra did not distinguish between goto, break, return, and continue. You can find many of his papers at: http://www.cs.utexas.edu/users/EWD/ What he was after was simple and maintainable code, and from everything I have read, I think he would have no major problems with the Linux kernel code. In the category of maintainability, and simplicity Dijkstra made certain the first hardware implementation of an interrupt handler he worked with had the ability to completely save the interrupt state so he could later return to the interrupted code. To make writing to a printer a non-realtime task he invented the semaphore. > Yeah, he did, but he's dead, and we shouldn't talk ill of the dead. Linus I think if he was alive you would have enjoyed talking to him, your view points seem to mesh quite well. > So > these days I can only rant about Niklaus Wirth, who took the "structured > programming" thing and enforced it in his languages (Pascal and Modula-2), > and thus forced his evil on untold generations of poor CS students who had > to learn langauges that weren't actually useful for real work. Now that is something worth criticizing! Though standard Pascal was not unusable because of the lack of a goto, that was the one feature it actually had. But I suspect a lot of teachers failed to mention it. > > (Yeah, yeah, most _practical_ versions of Pascal ended up having all the > stuff necessary to break structure, but as you may be able to tell, I was > one of the unwashed masses who had to write in "standard Pascal" in my > youth. I'm scarred for life). Well you seem to be coping well. Just a little Pascal phobia there... Eric ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 11:09 ` Eric W. Biederman @ 2003-01-13 14:34 ` Terje Eggestad 2003-01-13 23:23 ` Bob Taylor 1 sibling, 0 replies; 173+ messages in thread From: Terje Eggestad @ 2003-01-13 14:34 UTC (permalink / raw) To: Eric W. Biederman Cc: Linus Torvalds, Robert Love, Rob Wilkens, Christoph Hellwig, Greg KH, Alan Cox, William Lee Irwin III, Linux Kernel Mailing List On man, 2003-01-13 at 12:09, Eric W. Biederman wrote: > Linus Torvalds <torvalds@transmeta.com> writes: > > > On 12 Jan 2003, Robert Love wrote: > > > On Sun, 2003-01-12 at 15:22, Linus Torvalds wrote: > > > > > > > No, you've been brainwashed by CS people who thought that Niklaus > > > > Wirth actually knew what he was talking about. He didn't. He > > > > doesn't have a frigging clue. > > > > > > I thought Edsger Dijkstra coined the "gotos are evil" bit in his > > > structured programming push? > > > > Actually Edsger Dijkstra wrote a paper entitled "Goto considered Harmful" > He never called them evil. And the title was more for shock value to > grab peoples attention. For the beginners Dijkstra did not > distinguish between goto, break, return, and continue. > > You can find many of his papers at: > http://www.cs.utexas.edu/users/EWD/ > http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF to be exact. Reading it you can tell exactly how much of an mathematician Dijkstra really was. At these times It's best to keep in mind a quote: "I used to understand the Theory of Relativity, but then the mathematicians got hold of it." -- Albert Einstein > What he was after was simple and maintainable code, and from > everything I have read, I think he would have no major problems with > the Linux kernel code. > Well, in the formentioned paper he made the case that while - do, and do-while are superfluous; we should all use recursion instead. Out of respect of the dead, I'm not going to say what I think of that. Since C don't allow goto beyond it's function, most of what was problematic of goto's aren't legal anyway. But I submit that those that think goto's are evil never had to deal with smp locks. Most goto's I've seen deal with error handling, and I guess much could be "solved/hidden" with a "on_return { };" clause, but... An on_return would be a simplified try/trow/catch that is limited to the function. IMHO: a trow that is catch'ed somewhere up the call stack, is just as much an evil as goto. > > So > > these days I can only rant about Niklaus Wirth, who took the "structured > > programming" thing and enforced it in his languages (Pascal and Modula-2), > > and thus forced his evil on untold generations of poor CS students who had > > to learn langauges that weren't actually useful for real work. > > Now that is something worth criticizing! > Considering that students are bottled on Java these day, they're still learning a language unusable for real work. > > > > (Yeah, yeah, most _practical_ versions of Pascal ended up having all the > > stuff necessary to break structure, but as you may be able to tell, I was > > one of the unwashed masses who had to write in "standard Pascal" in my > > youth. I'm scarred for life). > > > Well you seem to be coping well. Just a little Pascal phobia there... > > Eric > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- _________________________________________________________________________ Terje Eggestad mailto:terje.eggestad@scali.no Scali Scalable Linux Systems http://www.scali.com Olaf Helsets Vei 6 tel: +47 22 62 89 61 (OFFICE) P.O.Box 150, Oppsal +47 975 31 574 (MOBILE) N-0619 Oslo fax: +47 22 62 89 51 NORWAY _________________________________________________________________________ ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 11:09 ` Eric W. Biederman 2003-01-13 14:34 ` Terje Eggestad @ 2003-01-13 23:23 ` Bob Taylor 1 sibling, 0 replies; 173+ messages in thread From: Bob Taylor @ 2003-01-13 23:23 UTC (permalink / raw) To: Linux Kernel Mailing List In message <m14r8dgvbe.fsf@frodo.biederman.org>, Eric W. Biederman writes: [snip] > Though standard Pascal was not unusable because of the lack of a goto, > that was the one feature it actually had. But I suspect a lot of > teachers failed to mention it. If my memory serves me, Niklaus Wirth invented Pascal as a teaching language not meant for production work. Modula, I think, was meant for production work. I don't care for either also. [snip] Bob -- +---------------------------------------------------------------+ | Bob Taylor Email: brtaylor@sanfelipe.com.mx | |---------------------------------------------------------------| | Like the ad says, at 300 dpi you can tell she's wearing a | | swimsuit. At 600 dpi you can tell it's wet. At 1200 dpi you | | can tell it's painted on. I suppose at 2400 dpi you can tell | | if the paint is giving her a rash. (So says Joshua R. Poulson)| +---------------------------------------------------------------+ ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 20:22 ` Linus Torvalds 2003-01-12 20:33 ` Robert Love @ 2003-01-12 20:48 ` Rob Wilkens 2003-01-12 20:59 ` Dimitrie O. Paun ` (3 more replies) 2003-01-13 3:30 ` yodaiken 2 siblings, 4 replies; 173+ messages in thread From: Rob Wilkens @ 2003-01-12 20:48 UTC (permalink / raw) To: Linus Torvalds Cc: Christoph Hellwig, Greg KH, Alan Cox, William Lee Irwin III, Linux Kernel Mailing List On Sun, 2003-01-12 at 15:22, Linus Torvalds wrote: > No, you've been brainwashed by CS people who thought that Niklaus Wirth > actually knew what he was talking about. He didn't. He doesn't have a > frigging clue. Ok, so you disagree with his style is what you're saying. You are free to disagree, that's your right. We're just from different schools. > Any if-statement is a goto. As are all structured loops. "structured" being a key word. I like structure in code. Let's face it, everyone likes code to be well structured, that's why there's the "CodingStyle" document -- people like the code to look a certain way so they can read it later. Without structure, you don't have that > Ans sometimes structure is good. When it's good, you should use it. Ok, we agree there. > And sometimes structure is _bad_, and gets into the way, and using a > "goto" is just much clearer. I can't foresee many scenarios where this would be the case. Someone spoke, for example, about being indented too far and needing to jump out because there isn't a good "break" mechanism... Well, as it says in the coding style document -- if you're indented more then 3 levels in, "you're screwed anyway, and should fix your program". In the code snippet you put up, I don't see structure as having been bad and a goto as having been clearer. > For example, it is quite common to have conditionals THAT DO NOT NEST. Could someone (Linus, I know your busy, so I won't ask you -- in fact, I'm amazed you'd bother to write to _me_ at all) please point me to sample code that illustrates this. I'm trying to envision "conditionals that do not nest that need goto". As near as I can tell, there must be some condition that the goto nests all the conditions in otherwise the goto wouldn't be needed. In some cases, Maybe what's between the goto and whats gone to should be broken up into a new function (modularized) and called independently of function that the goto was in. As someone else pointed out, it's provable that goto isn't needed, and given that C is a minimalist language, I'm not sure why it was included. > The Pascal language is a prime example of the latter problem. Because it > doesn't have a "break" statement, loops in (traditional) Pascal end up > often looking like total shit, because you have to add totally arbitrary > logic to say "I'm done now". But at least the code is "readable" when you do that. Sure it's a little more work on the part of the programmer. But anyone reading the code can say "oh, so the loop exits when condition x is met", rather than digging through the code looking for any place their might be a goto. Of course, I'm not about to argue that the kernel should be rewritten in PASCAL, nor am I interested in reinventing the wheel. We've got a good system here, let's just keep it good and make it better. (Notice I say "we" as if I've contributed something to it, whereas really I mean we including myself as an end-user.) -Rob ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 20:48 ` Rob Wilkens @ 2003-01-12 20:59 ` Dimitrie O. Paun 2003-01-12 22:48 ` any chance of 2.6.0-test*? -> goto example Willy Tarreau ` (2 subsequent siblings) 3 siblings, 0 replies; 173+ messages in thread From: Dimitrie O. Paun @ 2003-01-12 20:59 UTC (permalink / raw) To: robw, Linus Torvalds Cc: Christoph Hellwig, Greg KH, Alan Cox, William Lee Irwin III, Linux Kernel Mailing List On January 12, 2003 03:48 pm, Rob Wilkens wrote: > As someone else pointed out, it's provable that goto isn't needed, and > given that C is a minimalist language, I'm not sure why it was included. Rob, You should really try to post one controversial thing at a time... :) Anyway, all programming languages (minimalistic or not) are Turing complete, maybe you want to program in Turing-machine language? On a side note, I do hope you realize that Linus & Co. are considered by smart people in the business as being some of the best. And for good reason, too. That is to say, they are held in high esteem by a lot of very, _very_ smart people, based on their continuous review of the exceptional work done on the kernel. Now, doesn't it strike you a little bit odd that you come in here and find all this obvious "problems"? How come you are the only one seeing all thing things that any 1st year CS student should be able to spot, yet hundreds of the brightest minds in the business failed to notice? -- Dimi. ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? -> goto example 2003-01-12 20:48 ` Rob Wilkens 2003-01-12 20:59 ` Dimitrie O. Paun @ 2003-01-12 22:48 ` Willy Tarreau 2003-01-13 0:53 ` Rob Wilkens 2003-01-12 23:11 ` Coding style - (Was Re: any chance of 2.6.0-test*?) John Bradford 2003-01-13 11:07 ` any chance of 2.6.0-test*? Helge Hafting 3 siblings, 1 reply; 173+ messages in thread From: Willy Tarreau @ 2003-01-12 22:48 UTC (permalink / raw) To: Rob Wilkens Cc: Linus Torvalds, Christoph Hellwig, Greg KH, Alan Cox, William Lee Irwin III, Linux Kernel Mailing List Hi ! On Sun, Jan 12, 2003 at 03:48:24PM -0500, Rob Wilkens wrote: [...] > > For example, it is quite common to have conditionals THAT DO NOT NEST. > > Could someone (Linus, I know your busy, so I won't ask you -- in fact, > I'm amazed you'd bother to write to _me_ at all) please point me to > sample code that illustrates this. I'm trying to envision "conditionals > that do not nest that need goto". As near as I can tell, there must be > some condition that the goto nests all the conditions in otherwise the > goto wouldn't be needed. In some cases, Maybe what's between the goto > and whats gone to should be broken up into a new function (modularized) > and called independently of function that the goto was in. Look at any tree walking function or macro. Try to write an efficient one yourself, with lots of time the same tests and code to walk left, right, up or down. Always the same thing : just move pointers around and go on to the loop. Of course you can write it in your "clear structured" code, but I bet many people won't understand it because of the multiple nested tests. But a simple goto in each if statement to go to a common place is far cleaner. It's about the same as the final instruction in the for loop. > As someone else pointed out, it's provable that goto isn't needed, and > given that C is a minimalist language, I'm not sure why it was included. Of course it's provable. Anyway, any algorithm can also be written with a very complex S-K program ! But if you'd know how a processor works, you'd understand the evidence : about 1/5 of instructions is a branch (goto). The basics of computing are test, set and branch. Your while, for, if ... all do a mix of these. Why do you want to put the branch as a special case ? it's as much needed as others. And the only instruction which does only branch without test nor set is goto. What you do with your methods, is replacing a branch with a set, test then branch. More efficient ? I don't think so ! More readable ? I don't think so. Linus is right, you've been brainwashed :-) In fact, at school, thet tell you not to use goto to force you to learn how to use useful things such as the while loop. If you had used BASIC in the past, you'd remember how awful these programs were, not because of all the gotos, but because since we were never told the beauty of other methods, we simply used crappy gotos everywhere within left-justified code. > > The Pascal language is a prime example of the latter problem. Because it > > doesn't have a "break" statement, loops in (traditional) Pascal end up > > often looking like total shit, because you have to add totally arbitrary > > logic to say "I'm done now". > > But at least the code is "readable" when you do that. Sure it's a > little more work on the part of the programmer. and the CPU ! Fortunately, Borland added the break and continue statements so that their compiler could be used to produce good programs. > But anyone reading the > code can say "oh, so the loop exits when condition x is met", rather > than digging through the code looking for any place their might be a > goto. I prefer a "goto end_of_loop" than a "end_of_loop=1" followed by nested "if (!end_of_loop)" for each following blocks ! This way, you focus on what the code really does and not how the programmer could trick the compiler to tell the CPU what he wanted to really do. > -Rob Now, you asked for an example. Here is one. Please recode it without the gotos, try to keep it at least as readable, and then bench it ! I'll send you public apologies if you can make it either faster and as much readable, or as fast and much more readable. (yes, all the code sits within a for condition, just to allow 'break' within the loop !). As you see, I don't really mind writing awful primitives if they help upper levels being much cleaner and efficient. Cheers, Willy #define tree_foreach_destructive(__type, __root, __data, __stack, __slen) \ for (__slen = 0, __stack[0] = __root, __data = NULL; ({ \ __label__ __left, __right, __again, __end; \ typeof(__root) __ptr = __stack[__slen]; \ __again: \ __data = __ptr->data; \ if (__data != NULL) { \ __ptr->data = NULL; \ goto __end; \ } \ else if (__ptr->left != NULL) { \ __stack[++__slen] = __ptr = __ptr->left; \ goto __again; \ } \ else \ __left: \ if (__ptr->right != NULL) { \ __stack[++__slen] = __ptr = __ptr->right; \ goto __again; \ } \ else \ __right: \ if (!__slen--) \ goto __end; /* nothing left, don't delete the root node */ \ else { \ typeof (__root) __old; \ pool_free(__type, __ptr); \ __old = __ptr; \ __ptr = __stack[__slen]; \ if (__ptr->left == __old) { \ /* unlink this node from its parent */ \ __ptr->left = NULL; \ goto __left; \ } \ else { \ /* no need to unlink, the parent will also die */ \ goto __right; \ } \ } \ __end: \ (__slen >= 0); /* nothing after loop */}); ) ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? -> goto example 2003-01-12 22:48 ` any chance of 2.6.0-test*? -> goto example Willy Tarreau @ 2003-01-13 0:53 ` Rob Wilkens 2003-01-13 1:31 ` Willy Tarreau 0 siblings, 1 reply; 173+ messages in thread From: Rob Wilkens @ 2003-01-13 0:53 UTC (permalink / raw) To: Willy Tarreau; +Cc: Linux Kernel Mailing List On Sun, 2003-01-12 at 17:48, Willy Tarreau wrote: > Now, you asked for an example. Here is one. Please recode it without the The example you gave me wasn't valid C.. Well, from what I can tell it wasn't valid C, because the "for" statement had an opening "(", but no visible closing ")" .. And the "{" looked like it was in the wrong spot. If you want me to have something to benchmark against, I have to first be able to test and use your code, and if I can't use your code it's pointless to try to make it quicker. If you could provide (preferrably via web download or ftp) sample source that uses that function, it would speed up my ability to benchmark, thereafter I could submit improved code. -Rob ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? -> goto example 2003-01-13 0:53 ` Rob Wilkens @ 2003-01-13 1:31 ` Willy Tarreau 2003-01-13 16:10 ` Alexander Kellett 0 siblings, 1 reply; 173+ messages in thread From: Willy Tarreau @ 2003-01-13 1:31 UTC (permalink / raw) To: Rob Wilkens; +Cc: Willy Tarreau, Linux Kernel Mailing List On Sun, Jan 12, 2003 at 07:53:57PM -0500, Rob Wilkens wrote: > On Sun, 2003-01-12 at 17:48, Willy Tarreau wrote: > > Now, you asked for an example. Here is one. Please recode it without the > [...] > In fact, no where on the printed page did I > see a closing parenthesis for your for. Your giving me bad code to work > from. [...] > The example you gave me wasn't valid C.. [...] Well, first, I must say I've never seen such an arrogant beginner ! You even felt the need to send me two posts, one private, then nearly the same one to LKML. Poor guy, I gave you a piece of code to show you that your concepts were wrong when applied to reality, and all you try to do is to gain street credit. You will never learn because you whine before you think or search. Don't start a code review of the kernel or you'll get lots of ennemies ! > Well, from what I can tell it wasn't valid C, because the "for" statement > had an opening "(", but no visible closing ")" .. And the "{" looked like it > was in the wrong spot. >From what I can tell, you didn't even try to "info gcc" to check those wonderful gcc extensions which allow a complex instruction block inside an expression. The special construct ({ blabla }) is an expression which gets the value of the last evaluated expression. Now I'm fedup with explaining to you how to access basic information. Please unsubscribe, forget us and reboot under windows this way (I'm sure you're already reading your mail as root) : # lilo -u # reboot > If you want me to have something to benchmark against, I have to > first be able to test and use your code, and if I can't use your code > it's pointless to try to make it quicker. you'd need more code to be able to compile something. At least, I thought you were smart enough to imagine how to rework it as you did on Linus' code, but apparently I was wrong. > If you could provide (preferrably via web download or ftp) sample source > that uses that function, it would speed up my ability to benchmark, > thereafter I could submit improved code. I don't have all the parts of the code right at hand, and I don't know when/if I'll send them. For the moment, just try to understand what I sent to you and you can use this structure definition to understand better : struct ultree { unsigned long low; /* 32 bits low value of this node */ unsigned long high; /* 32 bits high value of this node, not used in 32 bits */ int level; /* bit level of this node */ void *data; /* carried data */ struct ultree *left, *right; /* children : left and right. NULL = leaf */ struct ultree *up; /* parent node. NULL = root */ }; Oh and if you have complaints about comments after the 80th column, remove them. And if the order of the declaration doesn't match your habits, just know that this is the order which gives me best performance, since swapping any 2 of its members induces a loss of about 20%. You know, L1, cache line size... all the things that your teachers didn't tell you because the story of the evil goto was better to keep children quiet ! Bye, Willy ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? -> goto example 2003-01-13 1:31 ` Willy Tarreau @ 2003-01-13 16:10 ` Alexander Kellett 2003-01-14 10:36 ` Helge Hafting 0 siblings, 1 reply; 173+ messages in thread From: Alexander Kellett @ 2003-01-13 16:10 UTC (permalink / raw) To: Willy Tarreau; +Cc: Rob Wilkens, Linux Kernel Mailing List On Mon, Jan 13, 2003 at 02:31:33AM +0100, Willy Tarreau wrote: > Oh and if you have complaints about comments after the 80th column, remove them. > And if the order of the declaration doesn't match your habits, just know that > this is the order which gives me best performance, since swapping any 2 of its > members induces a loss of about 20%. You know, L1, cache line size... all the > things that your teachers didn't tell you because the story of the evil goto was > better to keep children quiet ! :) As much as I absolutely love the utility of this piece of code you really do have to admit that it _is_ rather difficult to understand :) Is it so flawed of me to expect that some day this code could be rewritten in an extremely clean fashion and compilers made to do the work that was put in to make this fast? mvg, Alex -- "[...] Konqueror open source project. Weighing in at less than one tenth the size of another open source renderer" Apple, Jan 2003 (http://www.apple.com/safari/) ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? -> goto example 2003-01-13 16:10 ` Alexander Kellett @ 2003-01-14 10:36 ` Helge Hafting 0 siblings, 0 replies; 173+ messages in thread From: Helge Hafting @ 2003-01-14 10:36 UTC (permalink / raw) To: Alexander Kellett; +Cc: linux-kernel Alexander Kellett wrote: [...] > As much as I absolutely love the utility of this > piece of code you really do have to admit that it > _is_ rather difficult to understand :) > It is hard for everybody - until we get used to it. Then it is just another normal thing. :-) > Is it so flawed of me to expect that some day this > code could be rewritten in an extremely clean > fashion and compilers made to do the work that > was put in to make this fast? This is not flawed - but we actually need that compiler to exist, and become _common_ before replacing hand-optimizations with clean code. Feel free to join the gcc team and make the world better... Helge Hafting ^ permalink raw reply [flat|nested] 173+ messages in thread
* Coding style - (Was Re: any chance of 2.6.0-test*?) 2003-01-12 20:48 ` Rob Wilkens 2003-01-12 20:59 ` Dimitrie O. Paun 2003-01-12 22:48 ` any chance of 2.6.0-test*? -> goto example Willy Tarreau @ 2003-01-12 23:11 ` John Bradford 2003-01-13 11:07 ` any chance of 2.6.0-test*? Helge Hafting 3 siblings, 0 replies; 173+ messages in thread From: John Bradford @ 2003-01-12 23:11 UTC (permalink / raw) To: robw; +Cc: torvalds, hch, greg, alan, wli, linux-kernel [Most of a discussion about coding style removed] > As someone else pointed out, it's provable that goto isn't needed, and > given that C is a minimalist language, I'm not sure why it was included. It's worth keeping in mind, when coding in *any* language, that concepts such as loops, functions, and any kind of 'structured' programming, are all completely artificial concepts. Microprocessors are essentially based around: Loading discrete values to registers. Loading discrete values into memory locations. Copying a value from a register or a memory location, to another register or a memory location. Pushing and poping values on to and off of the stack. Jumping to another location based on whether a register contains zero or a non zero value. The only thing that can really be considered anything like structured programming is the stack, (and possibly interupts). > But at least the code is "readable" when you do that. Assember for a simple microprocessor such as a Z80 is arguable easier to understand than C source code for something like the Linux kernel. It's not the language, or how it is indented, that determines how difficult code is to read. It's the logic in the code. John. ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 20:48 ` Rob Wilkens ` (2 preceding siblings ...) 2003-01-12 23:11 ` Coding style - (Was Re: any chance of 2.6.0-test*?) John Bradford @ 2003-01-13 11:07 ` Helge Hafting 3 siblings, 0 replies; 173+ messages in thread From: Helge Hafting @ 2003-01-13 11:07 UTC (permalink / raw) To: robw, linux-kernel Rob Wilkens wrote: > > Any if-statement is a goto. As are all structured loops. > > "structured" being a key word. I like structure in code. Let's face > it, everyone likes code to be well structured, that's why there's the > "CodingStyle" document -- people like the code to look a certain way so > they can read it later. Without structure, you don't have that > If you like "structure" so much, consider the fact that gotos are used in a very structured way in the kernel. Books won't list goto as a "structured keyword" but that don't prevent it from being used in a structured and diciplined manner. "Avoid gotos" is only a rule of thumb, for those that don't know the finer points. Gotos have a enormous potential for abuse, but it isn't abused in the kernel because it is used by experts who limit themselves to only using it right. (Well, most of the time, but that isn't what you complain about. :-) One cannot expect a newbie to get this right while learning the language, so beginners get a "don't use gotos" rule. And therefore it takes time before they learn to read code containing gotos too - even _good_ code. Please note that rules of thumb aren't absolute. There is another well known - don't play with fire. Generally good, but some people have to do a lot of it anyway in order to design better fire extinguishers and train firefighters. > > Ans sometimes structure is good. When it's good, you should use it. > > Ok, we agree there. > > > And sometimes structure is _bad_, and gets into the way, and using a > > "goto" is just much clearer. > > I can't foresee many scenarios where this would be the case. Someone > spoke, for example, about being indented too far and needing to jump out > because there isn't a good "break" mechanism... Well, as it says in the > coding style document -- if you're indented more then 3 levels in, > "you're screwed anyway, and should fix your program". Sometimes using gotos makes things clearer, _for those that have some experience with this particular way of using gotos_. _Of course_ it isn't the clearest to _you_, because you, as a newbie, have noe training or experience in this. Get experience, learn to recognise the very limited use of goto in the kernel, and you'll probably agree. Consider someone who takes a C course where they don't teach "switch" because "if" can do the same thing. He would consider "switch" unnecessary. And hard to read, due to lack of experience. And just like you, he would urge people to not use switch because _he_ finds it harder to read. That doesn't make avoiding switch the right thing to do though. The same applies to goto. It is a useful thing - if used right. [...] > As someone else pointed out, it's provable that goto isn't needed, and > given that C is a minimalist language, I'm not sure why it was included. Again, switch is as unnecessary, yet nobody wants to remove it. And yes, switch can be abused too (replace all ifs with switch for example.) The rule against goto is a beginners simplification, because the real rules for using goto are harder to express. They are wasted on people who struggle with "for" and pointers - and then the beginners course ends. > > The Pascal language is a prime example of the latter problem. Because it > > doesn't have a "break" statement, loops in (traditional) Pascal end up > > often looking like total shit, because you have to add totally arbitrary > > logic to say "I'm done now". > > But at least the code is "readable" when you do that. Readable for who, is the question. Some limited use of goto don't take that long to learn. I used to simply think "urgh, a goto" but didn't complain - it wasn't _my_ kernel. Now I understand that kind of code and approve. And I shudder thinking about some code I've written for pay - doing ten allocations in a row, testing each, and freeing everything in a nested fashion upon possible failure. > Sure it's a > little more work on the part of the programmer. Now, if we can avoid that extra work _without_ harm, then it is certainly worth it, no? > But anyone reading the > code can say "oh, so the loop exits when condition x is met", rather > than digging through the code looking for any place their might be a > goto. What you describe is the problem with undiciplined use of goto. Kernel code don't use gotos in any arbitrary way. Check, and you'll see that 99% of it it is very diciplined, using gotos in one well-defined way. Much of it is explicitly coded function-internal "exceptions", a structured concept newer than C. (Yyou can surely find some bad examples too. Either hacks with a special reason, or things that really ought to be cleaned up.) > Of course, I'm not about to argue that the kernel should be rewritten > in PASCAL, nor am I interested in reinventing the wheel. We've got a > good system here, let's just keep it good and make it better. Making it better is interesting. Note that performance sometimes overrules style, and yes - there are cases where goto wins on raw performance. And that might pay off if it is a very often executed piece of code. Also, avoiding goto at all cost is extra work for programmers _every time_. Learning to use gotos "right" (I.e. advanced use of C) is one-time learning and then it is free - everytime. The use of gotos may be a learning curve for every kernel newbie, but so is understanding the VFS or the VM system or any other big complicated piece. Wether or not that piece uses gotos. :-) Helge Hafting ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 20:22 ` Linus Torvalds 2003-01-12 20:33 ` Robert Love 2003-01-12 20:48 ` Rob Wilkens @ 2003-01-13 3:30 ` yodaiken 2 siblings, 0 replies; 173+ messages in thread From: yodaiken @ 2003-01-13 3:30 UTC (permalink / raw) To: Linus Torvalds Cc: Rob Wilkens, Christoph Hellwig, Greg KH, Alan Cox, William Lee Irwin III, Linux Kernel Mailing List See Brian Kernighan's explanation in 1981. Still good. http://bit.csc.lsu.edu/tutorial/ten-commandments/bwk-on-pascal.html On Sun, Jan 12, 2003 at 12:22:26PM -0800, Linus Torvalds wrote: > > On Sun, 12 Jan 2003, Rob Wilkens wrote: > > > > However, I have always been taught, and have always believed that > > "goto"s are inherently evil. They are the creators of spaghetti code > > No, you've been brainwashed by CS people who thought that Niklaus Wirth > actually knew what he was talking about. He didn't. He doesn't have a > frigging clue. > > > (you start reading through the code to understand it (months or years > > after its written), and suddenly you jump to somewhere totally > > unrelated, and then jump somewhere else backwards, and it all gets ugly > > quickly). This makes later debugging of code total hell. > > Any if-statement is a goto. As are all structured loops. > > Ans sometimes structure is good. When it's good, you should use it. > > And sometimes structure is _bad_, and gets into the way, and using a > "goto" is just much clearer. > > For example, it is quite common to have conditionals THAT DO NOT NEST. > > In which case you have two possibilities > > - use goto, and be happy, since it doesn't enforce nesting > > This makes the code _more_ readable, since the code just does what > the algorithm says it should do. > > - duplicate the code, and rewrite it in a nesting form so that you can > use the structured jumps. > > This often makes the code much LESS readable, harder to maintain, > and bigger. > > The Pascal language is a prime example of the latter problem. Because it > doesn't have a "break" statement, loops in (traditional) Pascal end up > often looking like total shit, because you have to add totally arbitrary > logic to say "I'm done now". > > Linus > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- --------------------------------------------------------- Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com 1+ 505 838 9109 ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 19:59 ` Rob Wilkens ` (2 preceding siblings ...) 2003-01-12 20:22 ` Linus Torvalds @ 2003-01-12 21:29 ` Rik van Riel 2003-01-13 0:03 ` Scott Robert Ladd 2003-01-13 0:38 ` Randy Dunlap 5 siblings, 0 replies; 173+ messages in thread From: Rik van Riel @ 2003-01-12 21:29 UTC (permalink / raw) To: Rob Wilkens Cc: Linus Torvalds, Christoph Hellwig, Greg KH, Alan Cox, William Lee Irwin III, Linux Kernel Mailing List On Sun, 12 Jan 2003, Rob Wilkens wrote: > However, I have always been taught, and have always believed that > "goto"s are inherently evil. They are the creators of spaghetti code If the main flow of the code is through a bunch of hard to trace gotos and you choose to blame the tool instead of the programmer, I guess you could blame goto. However, the goto can also be a great tool to make the code more readable. The goto statement is, IMHO, one of the more elegant ways to code exceptions into a C function; that is, dealing with error situations that don't happen very often, in such a way that the error handling code doesn't clutter up the main code path. As an example, you could look at fs/super.c::do_kern_mount() mnt = alloc_vfsmnt(name); if (!mnt) goto out; sb = type->get_sb(type, flags, name, data); if (IS_ERR(sb)) goto out_mnt; Do you see how the absence of the error handling cleanup code makes the normal code path easier to read ? regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://guru.conectiva.com/ Current spamtrap: <a href=mailto:"october@surriel.com">october@surriel.com</a> ^ permalink raw reply [flat|nested] 173+ messages in thread
* RE: any chance of 2.6.0-test*? 2003-01-12 19:59 ` Rob Wilkens ` (3 preceding siblings ...) 2003-01-12 21:29 ` Rik van Riel @ 2003-01-13 0:03 ` Scott Robert Ladd 2003-01-13 0:38 ` Rob Wilkens 2003-01-13 0:38 ` Randy Dunlap 5 siblings, 1 reply; 173+ messages in thread From: Scott Robert Ladd @ 2003-01-13 0:03 UTC (permalink / raw) To: robw, Linus Torvalds Cc: Christoph Hellwig, Greg KH, Alan Cox, William Lee Irwin III, Linux Kernel Mailing List Rob Wilken wrote: > Would it be so terrible for you to change the code you had there to > _not_ use a goto and instead use something similar to what I suggested? > Never mind the philosophical arguments, I'm just talking good coding > style for a relatively small piece of code. > > If you want, but comments in your code to meaningfully describe what's > happening instead of goto labels. > > In general, if you can structure your code properly, you should never > need a goto, and if you don't need a goto you shouldn't use it. It's > just "common sense" as I've always been taught. Unless you're > intentionally trying to write code that's harder for others to read. I've spent some time looking through the kernel source code, getting a feel for the style and process before attempting to contribute something of my own. In most ways, the quality of Linux code equals or exceeds that of commercial products I've worked on. It may not be perfect, but I'd prefer that the maintainers focus on features and bug fixes, not religious issues. Your attitude against "goto" is perhaps based upon an excellent but dated article, "Goto Considered Harmful", written by Edsger W. Dijkstra, and published by the ACM in 1968. (A recent reprint can be found at http://www.acm.org/classics/oct95/.) As you can tell from the date, this article predates modern programming languages and idioms; it comes from a time when Fortran ruled, and before Fortran 77 provided significant tools for avoiding spaghetti code. A "goto" is not, in and of itself, dangerous -- it is a language feature, one that directly translates to the jump instructions implemented in machine code. Like pointers, operator overloading, and a host of other "perceived" evils in programming, "goto" is widely hated by those who've been bitten by poor programming. Bad code is the product of bad programmers; in my experience, a poor programmer will write a poor program, regardless of the availability of "goto." If you think people can't write spaghetti code in a "goto-less" language, I can send you some *lovely* examples to disabuse you of that notion. ;) Used over short distances with well-documented labels, a "goto" can be more effective, faster, and cleaner than a series of complex flags or other constructs. The "goto" may also be safer and more intuitive than the alternative. A "break" is a goto; a "continue" is a "goto" -- these are statements that move the point of execution explicitly. That said, I have used exactly two "goto" statements in all the lines of C, C++, Fortran 95, and (yes) COBOL I've written since leaving BASIC and Fortran IV behind. In one case, a single "goto" doubled the speed of a time-critical application; in the other case, "goto" shortens a segment of code by half and makes the algorithm much clearer. I would not use a goto willy-nilly for the fun of it -- unless I was entering an obfuscated code contest ;) We keep lowering the bar for technical prowess, it seems; if something has the potential to be used "wrong", high-minded designers remove the offending syntax rather than find or train competent programmers. This is why Java removes pointers (among other things) -- it's not that pointers aren't useful or efficient, it's that they require discipline from programmers. Just because something is dogma doesn't mean it is absolute truth. If anything, dogma should be sniffed quite carefully, since it tends to be rather rank if you get close enough. Removing goto is a religious choice, not a technical one. I could draw parallels with idiotic laws in general society, but this message is already marginal for this list. ..Scott -- Scott Robert Ladd Coyote Gulch Productions (http://www.coyotegulch.com) Professional programming for science and engineering; Interesting and unusual bits of very free code. ^ permalink raw reply [flat|nested] 173+ messages in thread
* RE: any chance of 2.6.0-test*? 2003-01-13 0:03 ` Scott Robert Ladd @ 2003-01-13 0:38 ` Rob Wilkens 2003-01-13 3:06 ` [OT] " J Sloan 2003-01-13 16:51 ` Emiliano Gabrielli 0 siblings, 2 replies; 173+ messages in thread From: Rob Wilkens @ 2003-01-13 0:38 UTC (permalink / raw) To: Scott Robert Ladd Cc: Linus Torvalds, Christoph Hellwig, Greg KH, Alan Cox, William Lee Irwin III, Linux Kernel Mailing List On Sun, 2003-01-12 at 19:03, Scott Robert Ladd wrote: > I've spent some time looking through the kernel source code, getting a feel > for the style and process before attempting to contribute something of my > own. In part that's why i haven't contributed too much of any actual code yet. I'm trying to get a feel for the code and the users. I figure the best way is to join the discussion list and follow the patches going in. > Your attitude against "goto" is perhaps based upon an excellent but dated > article, "Goto Considered Harmful", written by Edsger W. Dijkstra, and > published by the ACM in 1968. (A recent reprint can be found at > http://www.acm.org/classics/oct95/.) As you can tell from the date, this > article predates modern programming languages and idioms; it comes from a > time when Fortran ruled, and before Fortran 77 provided significant tools > for avoiding spaghetti code. It only goes to show that the core of computer science hasn't changed over the years. While some technology changes, the science itself stays the same. Much like a physicist should know the outdated theories of relativity by Albert Einstein (made way back in the 20th century as well) a good computer scientist should appreciate the contributions of its founders, and have a good grasp of their core contributions. I'm not claiming to be an expert in either field, however. Of course, this isn't a computer science mailing list, this is a linux kernel mailing list, so I apologize for getting off topic. Let's agree to drop it here. -Rob ^ permalink raw reply [flat|nested] 173+ messages in thread
* [OT] Re: any chance of 2.6.0-test*? 2003-01-13 0:38 ` Rob Wilkens @ 2003-01-13 3:06 ` J Sloan 2003-01-13 16:51 ` Emiliano Gabrielli 1 sibling, 0 replies; 173+ messages in thread From: J Sloan @ 2003-01-13 3:06 UTC (permalink / raw) To: linux-kernel; +Cc: robw Rob Wilkens wrote: >Of course, this isn't a computer science mailing list, this is a linux >kernel mailing list, so I apologize for getting off topic. > But it IS a computer science mailing list. Applied, practical, real world computer science - This is where the rubber meets the road - and interesting theories that don't cut the mustard in real life are discarded. :-) Best Regards, Joe ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 0:38 ` Rob Wilkens 2003-01-13 3:06 ` [OT] " J Sloan @ 2003-01-13 16:51 ` Emiliano Gabrielli 1 sibling, 0 replies; 173+ messages in thread From: Emiliano Gabrielli @ 2003-01-13 16:51 UTC (permalink / raw) To: robw, Scott Robert Ladd Cc: Linus Torvalds, Christoph Hellwig, Greg KH, Alan Cox, William Lee Irwin III, Linux Kernel Mailing List On 01:38, lunedì 13 gennaio 2003, Rob Wilkens wrote: > It only goes to show that the core of computer science hasn't changed > over the years. While some technology changes, the science itself stays > the same. Much like a physicist should know the outdated theories of > relativity by Albert Einstein (made way back in the 20th century as > well) a good computer scientist should appreciate the contributions of > its founders, and have a good grasp of their core contributions. I'm > not claiming to be an expert in either field, however. You think Relativity is outdated ?!? I can't beleave ! -- Emiliano Gabrielli dip. di Fisica 2° Università di Roma "Tor Vergata" ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 19:59 ` Rob Wilkens ` (4 preceding siblings ...) 2003-01-13 0:03 ` Scott Robert Ladd @ 2003-01-13 0:38 ` Randy Dunlap 5 siblings, 0 replies; 173+ messages in thread From: Randy Dunlap @ 2003-01-13 0:38 UTC (permalink / raw) To: robw; +Cc: torvalds, hch, greg, alan, wli, linux-kernel > On Sun, 2003-01-12 at 14:38, Linus Torvalds wrote: >> I think goto's are fine > > You're a relatively succesful guy, so I guess I shouldn't argue with your > style. Good. (although I don't know why I'm replying as this thread is way overdone....:) > However, I have always been taught, and have always believed that > "goto"s are inherently evil. They are the creators of spaghetti code (you > start reading through the code to understand it (months or years after its > written), and suddenly you jump to somewhere totally > unrelated, and then jump somewhere else backwards, and it all gets ugly > quickly). This makes later debugging of code total hell. > > Would it be so terrible for you to change the code you had there to _not_ > use a goto and instead use something similar to what I suggested? Never > mind the philosophical arguments, I'm just talking good coding style for a > relatively small piece of code. > > If you want, but comments in your code to meaningfully describe what's or put > happening instead of goto labels. > > In general, if you can structure your code properly, you should never need a > goto, and if you don't need a goto you shouldn't use it. It's just "common > sense" as I've always been taught. Unless you're > intentionally trying to write code that's harder for others to read. There are goto-less languages, even Algol-like ones. And OSes can be written in them. Well, they just have different names for JUMP. ~Randy ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 19:34 ` Rob Wilkens 2003-01-12 19:37 ` Rob Wilkens 2003-01-12 19:38 ` Linus Torvalds @ 2003-01-12 19:41 ` Christoph Hellwig 2003-01-12 19:41 ` Rob Wilkens 2003-01-12 20:31 ` Robert Love ` (4 subsequent siblings) 7 siblings, 1 reply; 173+ messages in thread From: Christoph Hellwig @ 2003-01-12 19:41 UTC (permalink / raw) To: Rob Wilkens Cc: Linus Torvalds, Christoph Hellwig, Greg KH, Alan Cox, William Lee Irwin III, Linux Kernel Mailing List On Sun, Jan 12, 2003 at 02:34:54PM -0500, Rob Wilkens wrote: > Linus, > > I'm REALLY opposed to the use of the word "goto" in any code where it's > not needed. Who cares? ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 19:41 ` Christoph Hellwig @ 2003-01-12 19:41 ` Rob Wilkens 2003-01-12 19:58 ` David Ford 0 siblings, 1 reply; 173+ messages in thread From: Rob Wilkens @ 2003-01-12 19:41 UTC (permalink / raw) To: Christoph Hellwig Cc: Linus Torvalds, Greg KH, Alan Cox, William Lee Irwin III, Linux Kernel Mailing List On Sun, 2003-01-12 at 14:41, Christoph Hellwig wrote: > On Sun, Jan 12, 2003 at 02:34:54PM -0500, Rob Wilkens wrote: > > Linus, > > > > I'm REALLY opposed to the use of the word "goto" in any code where it's > > not needed. > > Who cares? > I do. -Rob ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 19:41 ` Rob Wilkens @ 2003-01-12 19:58 ` David Ford 2003-01-12 20:07 ` Rob Wilkens 0 siblings, 1 reply; 173+ messages in thread From: David Ford @ 2003-01-12 19:58 UTC (permalink / raw) To: robw; +Cc: Linux Kernel Mailing List -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The horrific response to the use of "goto" is deprecated in favor of proper use. A function overloaded with gotos probably should be reworked. But there there is no need to outright avoid the use of 'goto'. if() is simply a conditional test with a goto A or goto B logic. There is a reason for the implementation of goto. When it all boils down to it, in assembler it's all a matter of JMP with or without a condition. David Rob Wilkens wrote: >On Sun, 2003-01-12 at 14:41, Christoph Hellwig wrote: > > >>On Sun, Jan 12, 2003 at 02:34:54PM -0500, Rob Wilkens wrote: >> >> >>>Linus, >>> >>>I'm REALLY opposed to the use of the word "goto" in any code where it's >>>not needed. >>> >>> >>Who cares? >> >> >> > >I do. > >-Rob > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+IcjV74cGT/9uvgsRAtPFAKDATzN7dkRyfRk7WXEDGyYe0oGiqACffj+X iXkDBQntdGnHeJFKjfmp0Lg= =l9hb -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 19:58 ` David Ford @ 2003-01-12 20:07 ` Rob Wilkens 2003-01-12 20:31 ` Oliver Neukum 2003-01-12 20:34 ` David Ford 0 siblings, 2 replies; 173+ messages in thread From: Rob Wilkens @ 2003-01-12 20:07 UTC (permalink / raw) To: David Ford; +Cc: Linux Kernel Mailing List On Sun, 2003-01-12 at 14:58, David Ford wrote: > The horrific response to the use of "goto" is deprecated in favor of > proper use. A function overloaded with gotos probably should be > reworked. But there there is no need to outright avoid the use of > 'goto'. if() is simply a conditional test with a goto A or goto B logic. But if the if() is already there, there is no need to have an additional goto in the statement, My version may even be faster than linus' version because it may save an extra assembler line of code (the beq or whatever branch statement generated by the if would do the branch during the if rather than after the if was evaluated and got to the first statement which was the goto). Of course, compiler optimizatoins probably make that particular point pointless to discuss. > There is a reason for the implementation of goto. When it all boils > down to it, in assembler it's all a matter of JMP with or without a > condition. But in this case, the condition was already there.. My point is that if you don't need a goto, you shouldn't use it. Whenever there's an obvious way not to use it, don't. -Rob ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 20:07 ` Rob Wilkens @ 2003-01-12 20:31 ` Oliver Neukum 2003-01-12 20:34 ` David Ford 1 sibling, 0 replies; 173+ messages in thread From: Oliver Neukum @ 2003-01-12 20:31 UTC (permalink / raw) To: robw, David Ford; +Cc: Linux Kernel Mailing List > But in this case, the condition was already there.. My point is that if > you don't need a goto, you shouldn't use it. Whenever there's an > obvious way not to use it, don't. You should not code to avoid a construction that's valid C. Just use the control structure that comes natural. Of course "if (c % 2) goto a;" is a crime, but things like "if (!buffer) goto err_out_nomem;" are better because the tell you why the code jumps here, it includes an implicit comment. if (buffer) { /* do stuff */ } else { return -ENOMEM; } just obscures the logic of the code. Or look at it another way, if you dislike goto you should crusade against conditional return as well. Regards Oliver ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 20:07 ` Rob Wilkens 2003-01-12 20:31 ` Oliver Neukum @ 2003-01-12 20:34 ` David Ford 1 sibling, 0 replies; 173+ messages in thread From: David Ford @ 2003-01-12 20:34 UTC (permalink / raw) To: robw; +Cc: Linux Kernel Mailing List -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Naturally. Evaluate the assembler when it's done. Normally an unconditional jump takes less cycles than a conditional jump. It's hard to argue with that. Use the right tool for the job. If the code expression necessitates a goto within a block of code to keep things neat and orderly, then do it. Regarding the if () { ... }, there are no braces around the assembler code. It's all a matter of linear instructions with jumps. An if() { ... } is a prettiness for our human eyes to organize code. David Rob Wilkens wrote: >On Sun, 2003-01-12 at 14:58, David Ford wrote: > > >>The horrific response to the use of "goto" is deprecated in favor of >>proper use. A function overloaded with gotos probably should be >>reworked. But there there is no need to outright avoid the use of >>'goto'. if() is simply a conditional test with a goto A or goto B logic. >> >> > >But if the if() is already there, there is no need to have an additional >goto in the statement, My version may even be faster than linus' >version because it may save an extra assembler line of code (the beq or >whatever branch statement generated by the if would do the branch during >the if rather than after the if was evaluated and got to the first >statement which was the goto). Of course, compiler optimizatoins >probably make that particular point pointless to discuss. > > > >>There is a reason for the implementation of goto. When it all boils >>down to it, in assembler it's all a matter of JMP with or without a >>condition. >> >> > >But in this case, the condition was already there.. My point is that if >you don't need a goto, you shouldn't use it. Whenever there's an >obvious way not to use it, don't. > >-Rob > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+IdFM74cGT/9uvgsRAuMkAJ4nKED1gEVvNKJiYqXg6J73aQgTRQCfWrrJ zYoHzuMjZ+ikKHCQ1O9E2C4= =PBlz -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 19:34 ` Rob Wilkens ` (2 preceding siblings ...) 2003-01-12 19:41 ` Christoph Hellwig @ 2003-01-12 20:31 ` Robert Love 2003-01-12 21:02 ` Rob Wilkens 2003-01-12 21:15 ` Matti Aarnio ` (3 subsequent siblings) 7 siblings, 1 reply; 173+ messages in thread From: Robert Love @ 2003-01-12 20:31 UTC (permalink / raw) To: robw Cc: Linus Torvalds, Christoph Hellwig, Greg KH, Alan Cox, William Lee Irwin III, Linux Kernel Mailing List On Sun, 2003-01-12 at 14:34, Rob Wilkens wrote: > I'm REALLY opposed to the use of the word "goto" in any code where > it's not needed. OF course, I'm a linux kernel newbie, so I'm in > no position to comment We use goto's extensively in the kernel. They generate fast, tight code. There is nothing wrong with being a newbie, but there is something wrong with voicing ignorance. "Learn first, form opinions later". When you start posting more than most of the developers here, combined, and none of your posts are contributive kernel code, there is a problem. Robert Love ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 20:31 ` Robert Love @ 2003-01-12 21:02 ` Rob Wilkens 0 siblings, 0 replies; 173+ messages in thread From: Rob Wilkens @ 2003-01-12 21:02 UTC (permalink / raw) To: Robert Love Cc: Linus Torvalds, Christoph Hellwig, Greg KH, Alan Cox, William Lee Irwin III, Linux Kernel Mailing List Mr. Love, I posted a minor change to the floppy driver which no one commented on earlier (probably in wrong form)-- three times now (once in unified diff format).. And you might even say that the message you quoted was kernel code that I was posting since I posted alternate code to linus' code. As per whether I post more than the developers here, it's only because I don't have a job, so I've got more free time than they do. I can't help it. If they're busier than me, I wouldn't expect them to waste time writing conversational messages about the kernel. -Rob On Sun, 2003-01-12 at 15:31, Robert Love wrote: > On Sun, 2003-01-12 at 14:34, Rob Wilkens wrote: > > > I'm REALLY opposed to the use of the word "goto" in any code where > > it's not needed. OF course, I'm a linux kernel newbie, so I'm in > > no position to comment > > We use goto's extensively in the kernel. They generate fast, tight > code. > > There is nothing wrong with being a newbie, but there is something wrong > with voicing ignorance. "Learn first, form opinions later". > > When you start posting more than most of the developers here, combined, > and none of your posts are contributive kernel code, there is a problem. > > Robert Love > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 19:34 ` Rob Wilkens ` (3 preceding siblings ...) 2003-01-12 20:31 ` Robert Love @ 2003-01-12 21:15 ` Matti Aarnio 2003-01-12 21:27 ` Rob Wilkens 2003-01-13 10:32 ` gotos in kernel [Was: Re: any chance of 2.6.0-test*?] Horst von Brand ` (2 subsequent siblings) 7 siblings, 1 reply; 173+ messages in thread From: Matti Aarnio @ 2003-01-12 21:15 UTC (permalink / raw) To: Rob Wilkens; +Cc: Linux Kernel Mailing List On Sun, Jan 12, 2003 at 02:34:54PM -0500, Rob Wilkens wrote: > Linus, > > I'm REALLY opposed to the use of the word "goto" in any code where it's > not needed. OF course, I'm a linux kernel newbie, so I'm in no position > to comment Bob, At first, read Documentation/CodingStyle of the kernel. Then have a look into: fs/open.c file do_sys_truncate() function. Explain how you can do that cleanly, understandably, and without code duplication, or ugly kludges without using those goto ? (And sticking to coding-style.) Also take into account, that there the most common execution path is direct, and exceptions are redirected elsewere. Original "gotos are evil" comes from days of FORTRAN (and BASIC) coding, where labels were all numeric, and definitely non-descriptive. Where nested conditionals didn't exist, etc. Source-code nesting didn't exist either... Doing things in moderation will usually produce better code, than strict sticking into some paradigm or other. Of course in schools there is definite need for severe whaking of sense into heads of the young would-be coders. Clean reusable and maintainable code is _hard_ to produce without any sort of role-models and rules, especially when kids teach coding for themselves by looking into other kids code of "look how clever spaghetti I made" stuff. When you learn the ropes (rules), and code enough (some years), you will finally learn where you can relax the rules a bit. Especially where the rules _must_ be altered to allow some formerly boo-boo styles. ... > If I'm misinterpreting the original code, then forgive me.. I just saw > a goto and gasped. There's always a better option than goto. Yes there are, but we are coding in C, nor C++ or Java... > -Rob /Matti Aarnio ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 21:15 ` Matti Aarnio @ 2003-01-12 21:27 ` Rob Wilkens 2003-01-12 21:40 ` Rik van Riel ` (7 more replies) 0 siblings, 8 replies; 173+ messages in thread From: Rob Wilkens @ 2003-01-12 21:27 UTC (permalink / raw) To: Matti Aarnio; +Cc: Linux Kernel Mailing List On Sun, 2003-01-12 at 16:15, Matti Aarnio wrote: > On Sun, Jan 12, 2003 at 02:34:54PM -0500, Rob Wilkens wrote: > > Linus, > > > > I'm REALLY opposed to the use of the word "goto" in any code where it's > > not needed. OF course, I'm a linux kernel newbie, so I'm in no position > > to comment > > Bob, > > At first, read Documentation/CodingStyle of the kernel. > Then have a look into: > > fs/open.c file do_sys_truncate() function. > > Explain how you can do that cleanly, understandably, and without > code duplication, or ugly kludges without using those goto ? > (And sticking to coding-style.) I've only compiled (and haven't tested this code), but it should be much faster than the original code. Why? Because we're eliminating an extra "jump" in several places in the code every time open would be called. Yes, it's more code, so the kernel is a little bigger, but it should be faster at the same time, and memory should be less of an issue nowadays. Here's the patch if you want to apply it (i have only compile tested it, I haven't booted with it).. This patch applied to the 2.5.56 kernel. --- open.c.orig 2003-01-12 16:17:01.000000000 -0500 +++ open.c 2003-01-12 16:22:32.000000000 -0500 @@ -100,44 +100,58 @@ error = -EINVAL; if (length < 0) /* sorry, but loff_t says... */ - goto out; + return error; error = user_path_walk(path, &nd); if (error) - goto out; + return error; inode = nd.dentry->d_inode; /* For directories it's -EISDIR, for other non-regulars - -EINVAL */ error = -EISDIR; - if (S_ISDIR(inode->i_mode)) - goto dput_and_out; + if (S_ISDIR(inode->i_mode)){ + path_release(&nd); + return error; + } error = -EINVAL; - if (!S_ISREG(inode->i_mode)) - goto dput_and_out; + if (!S_ISREG(inode->i_mode)){ + path_release(&nd); + return error; + } error = permission(inode,MAY_WRITE); - if (error) - goto dput_and_out; + if (error){ + path_release(&nd); + return error; + } error = -EROFS; - if (IS_RDONLY(inode)) - goto dput_and_out; + if (IS_RDONLY(inode)){ + path_release(&nd); + return error; + } error = -EPERM; - if (IS_IMMUTABLE(inode) || IS_APPEND(inode)) - goto dput_and_out; + if (IS_IMMUTABLE(inode) || IS_APPEND(inode)){ + path_release(&nd); + return error; + } /* * Make sure that there are no leases. */ error = break_lease(inode, FMODE_WRITE); - if (error) - goto dput_and_out; + if (error){ + path_release(&nd); + return error; + } error = get_write_access(inode); - if (error) - goto dput_and_out; + if (error){ + path_release(&nd); + return error; + } error = locks_verify_truncate(inode, NULL, length); if (!error) { @@ -146,9 +160,7 @@ } put_write_access(inode); -dput_and_out: path_release(&nd); -out: return error; } ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 21:27 ` Rob Wilkens @ 2003-01-12 21:40 ` Rik van Riel 2003-01-12 21:44 ` Rob Wilkens 2003-01-12 21:49 ` David Ford ` (6 subsequent siblings) 7 siblings, 1 reply; 173+ messages in thread From: Rik van Riel @ 2003-01-12 21:40 UTC (permalink / raw) To: Rob Wilkens; +Cc: Matti Aarnio, Linux Kernel Mailing List On Sun, 12 Jan 2003, Rob Wilkens wrote: > On Sun, 2003-01-12 at 16:15, Matti Aarnio wrote: > > At first, read Documentation/CodingStyle of the kernel. > > Then have a look into: > > > > fs/open.c file do_sys_truncate() function. > - if (S_ISDIR(inode->i_mode)) > - goto dput_and_out; > + if (S_ISDIR(inode->i_mode)){ > + path_release(&nd); > + return error; > + } [snip same change in a few more changes] OK, now imagine the dcache locking changing a little bit. You need to update this piece of (duplicated) code in half a dozen places in just this function and no doubt in dozens of other places all over fs/*.c. >From a maintenance point of view, a goto to a single block of error handling code is easier to maintain. regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://guru.conectiva.com/ Current spamtrap: <a href=mailto:"october@surriel.com">october@surriel.com</a> ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 21:40 ` Rik van Riel @ 2003-01-12 21:44 ` Rob Wilkens 2003-01-12 21:49 ` Aaron Lehmann ` (3 more replies) 0 siblings, 4 replies; 173+ messages in thread From: Rob Wilkens @ 2003-01-12 21:44 UTC (permalink / raw) To: Rik van Riel; +Cc: Matti Aarnio, Linux Kernel Mailing List On Sun, 2003-01-12 at 16:40, Rik van Riel wrote: > OK, now imagine the dcache locking changing a little bit. > You need to update this piece of (duplicated) code in half > a dozen places in just this function and no doubt in dozens > of other places all over fs/*.c. > > >From a maintenance point of view, a goto to a single block > of error handling code is easier to maintain. > There's no reason, though, that the error handling/cleanup code can't be in an entirely separate function, and if speed is needed, there's no reason it can't be an "inline" function. Or am I oversimplifying things again? -Rob ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 21:44 ` Rob Wilkens @ 2003-01-12 21:49 ` Aaron Lehmann 2003-01-12 22:07 ` Rob Wilkens 2003-01-12 21:58 ` Emiliano Gabrielli ` (2 subsequent siblings) 3 siblings, 1 reply; 173+ messages in thread From: Aaron Lehmann @ 2003-01-12 21:49 UTC (permalink / raw) To: Rob Wilkens; +Cc: Rik van Riel, Matti Aarnio, Linux Kernel Mailing List On Sun, Jan 12, 2003 at 04:44:05PM -0500, Rob Wilkens wrote: > There's no reason, though, that the error handling/cleanup code can't be > in an entirely separate function, and if speed is needed, there's no > reason it can't be an "inline" function. Or am I oversimplifying things > again? Remind me why this is better than a goto? ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 21:49 ` Aaron Lehmann @ 2003-01-12 22:07 ` Rob Wilkens 2003-01-12 22:18 ` Aaron Lehmann 0 siblings, 1 reply; 173+ messages in thread From: Rob Wilkens @ 2003-01-12 22:07 UTC (permalink / raw) To: Aaron Lehmann; +Cc: Rik van Riel, Matti Aarnio, Linux Kernel Mailing List In the case of an inline function, you're saving a jump, because the code that you would "goto" is right there in sequence with the code you are executing as far as the processor is concerned. In essence, you're duplicating code, but you're not retyping code, and your keeping code consistent accross all uses of it (keeping it modular). It's trivial, but where you're trying to cut down on the total number of instructions executed in kernel mode, you would think even where you could save one instructon (and branches are expensive, no?) you would want to. -Rob On Sun, 2003-01-12 at 16:49, Aaron Lehmann wrote: > On Sun, Jan 12, 2003 at 04:44:05PM -0500, Rob Wilkens wrote: > > There's no reason, though, that the error handling/cleanup code can't be > > in an entirely separate function, and if speed is needed, there's no > > reason it can't be an "inline" function. Or am I oversimplifying things > > again? > > Remind me why this is better than a goto? ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 22:07 ` Rob Wilkens @ 2003-01-12 22:18 ` Aaron Lehmann 2003-01-12 22:34 ` Rob Wilkens 0 siblings, 1 reply; 173+ messages in thread From: Aaron Lehmann @ 2003-01-12 22:18 UTC (permalink / raw) To: Rob Wilkens; +Cc: Rik van Riel, Matti Aarnio, Linux Kernel Mailing List On Sun, Jan 12, 2003 at 05:07:19PM -0500, Rob Wilkens wrote: > In the case of an inline function, you're saving a jump, because the > code that you would "goto" is right there in sequence with the code you > are executing as far as the processor is concerned. In essence, you're > duplicating code, but you're not retyping code, and your keeping code > consistent accross all uses of it (keeping it modular). These are usually error conditions. If you inline them, you will have to jump *over* them as part of the normal code path. You don't save any instructions, and you end up with a kernel which has much more duplicated code and thus thrashes the cache more. It also makes the code harder to read. goto makes it easy "stack" error handlers and not worry about the order in which you do clean up. ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 22:18 ` Aaron Lehmann @ 2003-01-12 22:34 ` Rob Wilkens 2003-01-12 22:52 ` Aaron Lehmann ` (3 more replies) 0 siblings, 4 replies; 173+ messages in thread From: Rob Wilkens @ 2003-01-12 22:34 UTC (permalink / raw) To: Aaron Lehmann; +Cc: Rik van Riel, Matti Aarnio, Linux Kernel Mailing List On Sun, 2003-01-12 at 17:18, Aaron Lehmann wrote: > These are usually error conditions. If you inline them, you will have > to jump *over* them as part of the normal code path. You don't save You're wrong. You wouldn't have to jump over them any more than you have to jump over the "goto" statement. They would be where the goto statement is. Instead of the goto you would have the function. > any instructions, and you end up with a kernel which has much more > duplicated code and thus thrashes the cache more. It also makes the If that argument was taken to it's logical conclusion (and I did, in my mind just now), no one should add any code the grows the kernel at all. -Rob ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 22:34 ` Rob Wilkens @ 2003-01-12 22:52 ` Aaron Lehmann 2003-01-12 23:11 ` Rob Wilkens 2003-01-12 22:53 ` Sean Neakums ` (2 subsequent siblings) 3 siblings, 1 reply; 173+ messages in thread From: Aaron Lehmann @ 2003-01-12 22:52 UTC (permalink / raw) To: Rob Wilkens; +Cc: Rik van Riel, Matti Aarnio, Linux Kernel Mailing List On Sun, Jan 12, 2003 at 05:34:58PM -0500, Rob Wilkens wrote: > You're wrong. You wouldn't have to jump over them any more than you > have to jump over the "goto" statement. The goto is a conditional jump. You propose replacing it with a conditional jump past the error handling code predicated on the opposite condition. Where's the improvement? > > any instructions, and you end up with a kernel which has much more > > duplicated code and thus thrashes the cache more. It also makes the > > If that argument was taken to it's logical conclusion (and I did, in my > mind just now), no one should add any code the grows the kernel at all. Not without good reason. ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 22:52 ` Aaron Lehmann @ 2003-01-12 23:11 ` Rob Wilkens 2003-01-12 23:31 ` Oliver Neukum 2003-01-12 23:39 ` Emiliano Gabrielli 0 siblings, 2 replies; 173+ messages in thread From: Rob Wilkens @ 2003-01-12 23:11 UTC (permalink / raw) To: Aaron Lehmann; +Cc: Rik van Riel, Matti Aarnio, Linux Kernel Mailing List On Sun, 2003-01-12 at 17:52, Aaron Lehmann wrote: > On Sun, Jan 12, 2003 at 05:34:58PM -0500, Rob Wilkens wrote: > > You're wrong. You wouldn't have to jump over them any more than you > > have to jump over the "goto" statement. > > The goto is a conditional jump. You propose replacing it with a > conditional jump past the error handling code predicated on the > opposite condition. Where's the improvement? The goto is absolutely not a conditional jump. The if that precedes it is conditional. The goto is not. The if is already there. -Rob ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 23:11 ` Rob Wilkens @ 2003-01-12 23:31 ` Oliver Neukum 2003-01-12 23:39 ` Emiliano Gabrielli 1 sibling, 0 replies; 173+ messages in thread From: Oliver Neukum @ 2003-01-12 23:31 UTC (permalink / raw) To: robw, Aaron Lehmann; +Cc: Rik van Riel, Matti Aarnio, Linux Kernel Mailing List Am Montag, 13. Januar 2003 00:11 schrieb Rob Wilkens: > On Sun, 2003-01-12 at 17:52, Aaron Lehmann wrote: > > On Sun, Jan 12, 2003 at 05:34:58PM -0500, Rob Wilkens wrote: > > > You're wrong. You wouldn't have to jump over them any more than you > > > have to jump over the "goto" statement. > > > > The goto is a conditional jump. You propose replacing it with a > > conditional jump past the error handling code predicated on the > > opposite condition. Where's the improvement? > > The goto is absolutely not a conditional jump. The if that precedes it > is conditional. The goto is not. The if is already there. Oh, well. Apologies first, my assembler is rusty. if (a == NULL) goto err_out; bad compiler -> tst $D0 ; evaluate a == NULL bne L1 ; this is the if bra err_out ; this is the goto L1: good compiler -> tst $D0 beq err_out ; obvious optimisation Oliver ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 23:11 ` Rob Wilkens 2003-01-12 23:31 ` Oliver Neukum @ 2003-01-12 23:39 ` Emiliano Gabrielli 2003-01-12 23:46 ` Rob Wilkens 1 sibling, 1 reply; 173+ messages in thread From: Emiliano Gabrielli @ 2003-01-12 23:39 UTC (permalink / raw) To: robw; +Cc: aaronl, riel, matti.aarnio, linux-kernel <quote who="Rob Wilkens"> > On Sun, 2003-01-12 at 17:52, Aaron Lehmann wrote: >> On Sun, Jan 12, 2003 at 05:34:58PM -0500, Rob Wilkens wrote: >> > You're wrong. You wouldn't have to jump over them any more than you have to jump >> over the "goto" statement. >> >> The goto is a conditional jump. You propose replacing it with a >> conditional jump past the error handling code predicated on the >> opposite condition. Where's the improvement? > > The goto is absolutely not a conditional jump. The if that precedes it is > conditional. The goto is not. The if is already there. > > -Rob Oh my God ... really you are the only one on this list not to understand that hi has mispelled ?!? Now I understand the reason of your trollness !! -- Emiliano Gabrielli dip. di Fisica 2° Università di Roma "Tor Vergata" ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 23:39 ` Emiliano Gabrielli @ 2003-01-12 23:46 ` Rob Wilkens 2003-01-12 23:57 ` Emiliano Gabrielli 0 siblings, 1 reply; 173+ messages in thread From: Rob Wilkens @ 2003-01-12 23:46 UTC (permalink / raw) To: Emiliano Gabrielli; +Cc: aaronl, riel, matti.aarnio, linux-kernel On Sun, 2003-01-12 at 18:39, Emiliano Gabrielli wrote: > Now I understand the reason of your trollness !! Enough with the personal attacks.. They get you know where, I'm not botherred by them, and they clog the list. -Rob ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 23:46 ` Rob Wilkens @ 2003-01-12 23:57 ` Emiliano Gabrielli 2003-01-13 0:08 ` Rob Wilkens 0 siblings, 1 reply; 173+ messages in thread From: Emiliano Gabrielli @ 2003-01-12 23:57 UTC (permalink / raw) To: robw; +Cc: aaronl, riel, matti.aarnio, linux-kernel <quote who="Rob Wilkens"> > On Sun, 2003-01-12 at 18:39, Emiliano Gabrielli wrote: >> Now I understand the reason of your trollness !! > > Enough with the personal attacks.. They get you know where, I'm not botherred by them, > and they clog the list. > > -Rob Ok, my apologises... what I would say is "why don't you sit for a moment and think about what a lot of skilled coder said you ???" What I can't understand in you is the reason of your insistence, ... cheers :-) -- Emiliano Gabrielli dip. di Fisica 2° Università di Roma "Tor Vergata" ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 23:57 ` Emiliano Gabrielli @ 2003-01-13 0:08 ` Rob Wilkens 2003-01-13 16:02 ` Terje Eggestad 0 siblings, 1 reply; 173+ messages in thread From: Rob Wilkens @ 2003-01-13 0:08 UTC (permalink / raw) To: Emiliano Gabrielli; +Cc: aaronl, riel, matti.aarnio, linux-kernel On Sun, 2003-01-12 at 18:57, Emiliano Gabrielli wrote: > Ok, my apologises... what I would say is "why don't you sit for a moment and think about > what a lot of skilled coder said you ???" Believe me when I say, I'm learning a lot from these discussions. Hey, that's what I'm here for. And that's what the list is about in some respect (discussion). Call me a troll if you want, call me a cockroach if it makes you feel better. I don't care. But in the end, I'm saying what I think is right, and when I'm wrong, I'm learning the whys. If I still think I'm right, I'm saying so, and people explain vividly exactly why it is that I'm wrong, and believe it or not, I do learn. Sometimes I learn at a different rate than others, but that's only because I have a different background and a different set of learning disabilities. -Rob ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 0:08 ` Rob Wilkens @ 2003-01-13 16:02 ` Terje Eggestad 0 siblings, 0 replies; 173+ messages in thread From: Terje Eggestad @ 2003-01-13 16:02 UTC (permalink / raw) To: robw; +Cc: linux-kernel On man, 2003-01-13 at 01:08, Rob Wilkens wrote: > On Sun, 2003-01-12 at 18:57, Emiliano Gabrielli wrote: > > Ok, my apologises... what I would say is "why don't you sit for a moment and think about > > what a lot of skilled coder said you ???" > > Believe me when I say, I'm learning a lot from these discussions. Hey, I'm sure > that's what I'm here for. And that's what the list is about in some > respect (discussion). THat's NOT why we're here. People are on this list to do work, not to be teaching assistants. That's why You're considered disrespectful. > Call me a troll if you want, call me a cockroach > if it makes you feel better. I don't care. But in the end, I'm saying > what I think is right, and when I'm wrong, I'm learning the whys. If I > still think I'm right, I'm saying so, and people explain vividly exactly > why it is that I'm wrong, and believe it or not, I do learn. Sometimes > I learn at a different rate than others, but that's only because I have > a different background and a different set of learning disabilities. > > -Rob > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- _________________________________________________________________________ Terje Eggestad mailto:terje.eggestad@scali.no Scali Scalable Linux Systems http://www.scali.com Olaf Helsets Vei 6 tel: +47 22 62 89 61 (OFFICE) P.O.Box 150, Oppsal +47 975 31 574 (MOBILE) N-0619 Oslo fax: +47 22 62 89 51 NORWAY _________________________________________________________________________ ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 22:34 ` Rob Wilkens 2003-01-12 22:52 ` Aaron Lehmann @ 2003-01-12 22:53 ` Sean Neakums 2003-01-12 23:06 ` Oliver Neukum 2003-01-12 23:48 ` Rik van Riel 3 siblings, 0 replies; 173+ messages in thread From: Sean Neakums @ 2003-01-12 22:53 UTC (permalink / raw) To: linux-kernel commence Rob Wilkens quotation: > On Sun, 2003-01-12 at 17:18, Aaron Lehmann wrote: >> These are usually error conditions. If you inline them, you will have >> to jump *over* them as part of the normal code path. You don't save > > You're wrong. You wouldn't have to jump over them any more than you > have to jump over the "goto" statement. They would be where the goto > statement is. Instead of the goto you would have the function. He said the *normal* path. Jumping to error code is rarely a normal path. By replacing the gotos with inlined functions, you turn the fast path into a bunch of jumps over duplicated error code, and the error path into a straight line. >> any instructions, and you end up with a kernel which has much more >> duplicated code and thus thrashes the cache more. It also makes the > > If that argument was taken to it's logical conclusion (and I did, in my > mind just now), no one should add any code the grows the kernel at all. The interesting thing about taking arguments to their logical conclusion is that it rarely makes any sense to do so. -- / | [|] Sean Neakums | Questions are a burden to others; [|] <sneakums@zork.net> | answers a prison for oneself. \ | ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 22:34 ` Rob Wilkens 2003-01-12 22:52 ` Aaron Lehmann 2003-01-12 22:53 ` Sean Neakums @ 2003-01-12 23:06 ` Oliver Neukum 2003-01-12 23:48 ` Rik van Riel 3 siblings, 0 replies; 173+ messages in thread From: Oliver Neukum @ 2003-01-12 23:06 UTC (permalink / raw) To: robw, Aaron Lehmann; +Cc: Linux Kernel Mailing List Am Sonntag, 12. Januar 2003 23:34 schrieb Rob Wilkens: > On Sun, 2003-01-12 at 17:18, Aaron Lehmann wrote: > > These are usually error conditions. If you inline them, you will have > > to jump *over* them as part of the normal code path. You don't save > > You're wrong. You wouldn't have to jump over them any more than you > have to jump over the "goto" statement. They would be where the goto > statement is. Instead of the goto you would have the function. That exactly is the problem. If they are where the goto would be they needlessly fill the CPU's pipeline, take up space in L1 and use up bandwidth on the busses. A goto is much shorter than a cleanup. And you would have to jump. Any control structure will result in one or more conditional jumps in the assembler code (or conditional instructions) Turning "if (a) goto b;" into a single branch instruction is trivial. The best the compiler can do with if (a) { cleanup(); return err; } is putting the conditional code on the end of the function. So in the best case the compiler can generate almost equivalent code at a cost of maintainability. > > any instructions, and you end up with a kernel which has much more > > duplicated code and thus thrashes the cache more. It also makes the > > If that argument was taken to it's logical conclusion (and I did, in my > mind just now), no one should add any code the grows the kernel at all. Correct. If you mean that literally, you've grasped an important concept. You grow the kernel only with good cause. And you look where you add the code. Additional device drivers don't hurt. A computed jump is still only one computed jump. Additional code in common code paths of the core hurts a lot. For the inner loops of core code there are two considerations, size and reducing jumps. Regards Oliver ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 22:34 ` Rob Wilkens ` (2 preceding siblings ...) 2003-01-12 23:06 ` Oliver Neukum @ 2003-01-12 23:48 ` Rik van Riel 3 siblings, 0 replies; 173+ messages in thread From: Rik van Riel @ 2003-01-12 23:48 UTC (permalink / raw) To: Rob Wilkens; +Cc: Aaron Lehmann, Matti Aarnio, Linux Kernel Mailing List On Sun, 12 Jan 2003, Rob Wilkens wrote: > ... jump over the "goto" statement. Umm, an if + goto IS a conditional jump. A modern compiler will simply turn the goto into a conditional jump, meaning that the normal code path doesn't do any jumps. cheers, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://guru.conectiva.com/ Current spamtrap: <a href=mailto:"october@surriel.com">october@surriel.com</a> ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 21:44 ` Rob Wilkens 2003-01-12 21:49 ` Aaron Lehmann @ 2003-01-12 21:58 ` Emiliano Gabrielli 2003-01-12 22:12 ` Rob Wilkens 2003-01-12 22:12 ` Oliver Neukum 2003-01-13 8:15 ` Jens Axboe 3 siblings, 1 reply; 173+ messages in thread From: Emiliano Gabrielli @ 2003-01-12 21:58 UTC (permalink / raw) To: linux-kernel <quote who="Rob Wilkens"> > On Sun, 2003-01-12 at 16:40, Rik van Riel wrote: >> OK, now imagine the dcache locking changing a little bit. >> You need to update this piece of (duplicated) code in half >> a dozen places in just this function and no doubt in dozens >> of other places all over fs/*.c. >> >> >From a maintenance point of view, a goto to a single block >> of error handling code is easier to maintain. >> > > There's no reason, though, that the error handling/cleanup code can't be in an > entirely separate function, and if speed is needed, there's no reason it can't be an > "inline" function. Or am I oversimplifying things again? > > -Rob > you do, if you inline the code and every drive writer use this tecnique the kernel will be much bigger don't you think ?!? Makeing a simple function instead is quite slower I think... don't forget that goto are used only in error recovery routines ... You can simply build a "stack" of labels .. IMHO this is a great way to be sure of the right order we are performing cleanup/recovery ... -- Emiliano Gabrielli dip. di Fisica 2° Università di Roma "Tor Vergata" ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 21:58 ` Emiliano Gabrielli @ 2003-01-12 22:12 ` Rob Wilkens 2003-01-12 22:29 ` Olivier Galibert 2003-01-12 23:21 ` Alan Cox 0 siblings, 2 replies; 173+ messages in thread From: Rob Wilkens @ 2003-01-12 22:12 UTC (permalink / raw) To: Emiliano Gabrielli; +Cc: linux-kernel On Sun, 2003-01-12 at 16:58, Emiliano Gabrielli wrote: > you do, if you inline the code and every drive writer use this tecnique the kernel will > be much bigger don't you think ?!? Kernel size (footprint in memory) would grow a tad bit (not much), but it's overall speed would also go up. > Makeing a simple function instead is quite slower I think... don't forget that goto are > used only in error recovery routines ... That wasn't the case in Torvalds' sample code which started this thread. That was spin-locking code, I believe. Of course, in that case, there was no need for an inline function or anything, but rather restructuring of an if statement. > You can simply build a "stack" of labels .. IMHO this is a great way to be sure of the > right order we are performing cleanup/recovery ... If the kernel developer "knows" always that they have to follow the stack order when adding additional cases, it's fine. But it is more obvious in the patch I wrote what is going on than in the original "goto" version of the code with the fs/open.c code someone asked me to look at. This makes it harder for people unfamiliar with the complete linux kernel design in this area to get started. Of course, I'm getting a crash course it seems. -Rob ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 22:12 ` Rob Wilkens @ 2003-01-12 22:29 ` Olivier Galibert 2003-01-12 23:21 ` Alan Cox 1 sibling, 0 replies; 173+ messages in thread From: Olivier Galibert @ 2003-01-12 22:29 UTC (permalink / raw) To: linux-kernel On Sun, Jan 12, 2003 at 05:12:42PM -0500, Rob Wilkens wrote: > Kernel size (footprint in memory) would grow a tad bit (not much), but > it's overall speed would also go up. No, it would go down. The damage may not be too great thanks to GCSE, but even that isn't sure especially if asms (via locking code) are involved. You really need to brush up on current computer architectures. Look in particular the L1 caches structures, cacheline sizes, cache sizes and branch prediction. And of course current compiler technology, so that you actually know what code is generated. OG. PS: I know, don't feed the troll, sorry. ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 22:12 ` Rob Wilkens 2003-01-12 22:29 ` Olivier Galibert @ 2003-01-12 23:21 ` Alan Cox 1 sibling, 0 replies; 173+ messages in thread From: Alan Cox @ 2003-01-12 23:21 UTC (permalink / raw) To: robw; +Cc: Emiliano Gabrielli, Linux Kernel Mailing List On Sun, 2003-01-12 at 22:12, Rob Wilkens wrote: > On Sun, 2003-01-12 at 16:58, Emiliano Gabrielli wrote: > > you do, if you inline the code and every drive writer use this tecnique the kernel will > > be much bigger don't you think ?!? > > Kernel size (footprint in memory) would grow a tad bit (not much), but > it's overall speed would also go up. Wrong. Thats the trouble with programming an abstract level. People just don't understand the real world. Cache is everything, small cache footprint is king. Alan ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 21:44 ` Rob Wilkens 2003-01-12 21:49 ` Aaron Lehmann 2003-01-12 21:58 ` Emiliano Gabrielli @ 2003-01-12 22:12 ` Oliver Neukum 2003-01-12 22:18 ` Aaron Lehmann 2003-01-13 8:15 ` Jens Axboe 3 siblings, 1 reply; 173+ messages in thread From: Oliver Neukum @ 2003-01-12 22:12 UTC (permalink / raw) To: robw, Rik van Riel; +Cc: Matti Aarnio, Linux Kernel Mailing List Am Sonntag, 12. Januar 2003 22:44 schrieb Rob Wilkens: > On Sun, 2003-01-12 at 16:40, Rik van Riel wrote: > > OK, now imagine the dcache locking changing a little bit. > > You need to update this piece of (duplicated) code in half > > a dozen places in just this function and no doubt in dozens > > of other places all over fs/*.c. > > > > >From a maintenance point of view, a goto to a single block > > > > of error handling code is easier to maintain. > > There's no reason, though, that the error handling/cleanup code can't be > in an entirely separate function, and if speed is needed, there's no > reason it can't be an "inline" function. Or am I oversimplifying things > again? Yes. Typical error cleanup looks like: err_out: up(&sem); return err; Releasing a lock in another function is a crime punished by slow death. (Some might even resort to voodoo to make sure your shadow suffers in the beyond.) It makes code absolutely unreadable. Regards Oliver ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 22:12 ` Oliver Neukum @ 2003-01-12 22:18 ` Aaron Lehmann 2003-01-12 22:35 ` Rob Wilkens 0 siblings, 1 reply; 173+ messages in thread From: Aaron Lehmann @ 2003-01-12 22:18 UTC (permalink / raw) To: Oliver Neukum; +Cc: robw, Rik van Riel, Matti Aarnio, Linux Kernel Mailing List On Sun, Jan 12, 2003 at 11:12:41PM +0100, Oliver Neukum wrote: > Yes. Typical error cleanup looks like: > err_out: > up(&sem); > return err; > > Releasing a lock in another function is a crime punished by slow death. Not to mention that the 'return err;' statement is hard to move to an inline function meaningfully. ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 22:18 ` Aaron Lehmann @ 2003-01-12 22:35 ` Rob Wilkens 0 siblings, 0 replies; 173+ messages in thread From: Rob Wilkens @ 2003-01-12 22:35 UTC (permalink / raw) To: Aaron Lehmann Cc: Oliver Neukum, Rik van Riel, Matti Aarnio, Linux Kernel Mailing List On Sun, 2003-01-12 at 17:18, Aaron Lehmann wrote: > On Sun, Jan 12, 2003 at 11:12:41PM +0100, Oliver Neukum wrote: > > Yes. Typical error cleanup looks like: > > err_out: > > up(&sem); > > return err; > > > > Releasing a lock in another function is a crime punished by slow death. > > Not to mention that the 'return err;' statement is hard to move to an > inline function meaningfully. Not that hard: You just "return functionname()" where functionname is the name of your inline function that returns the value you want to return. -Rob ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 21:44 ` Rob Wilkens ` (2 preceding siblings ...) 2003-01-12 22:12 ` Oliver Neukum @ 2003-01-13 8:15 ` Jens Axboe 3 siblings, 0 replies; 173+ messages in thread From: Jens Axboe @ 2003-01-13 8:15 UTC (permalink / raw) To: Rob Wilkens, Rik van Riel; +Cc: Matti Aarnio, Linux Kernel Mailing List On Sun, Jan 12 2003, Rob Wilkens wrote: > On Sun, 2003-01-12 at 16:40, Rik van Riel wrote: > > OK, now imagine the dcache locking changing a little bit. > > You need to update this piece of (duplicated) code in half > > a dozen places in just this function and no doubt in dozens > > of other places all over fs/*.c. > > > > >From a maintenance point of view, a goto to a single block > > of error handling code is easier to maintain. > > > > There's no reason, though, that the error handling/cleanup code can't be > in an entirely separate function, and if speed is needed, there's no > reason it can't be an "inline" function. Or am I oversimplifying things > again? *plonk* -- Jens Axboe ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 21:27 ` Rob Wilkens 2003-01-12 21:40 ` Rik van Riel @ 2003-01-12 21:49 ` David Ford 2003-01-13 19:22 ` [OffTopic] [apology] " Rob Wilkens 2003-01-12 21:59 ` Adam Kropelin ` (5 subsequent siblings) 7 siblings, 1 reply; 173+ messages in thread From: David Ford @ 2003-01-12 21:49 UTC (permalink / raw) To: robw, Linux Kernel Mailing List -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 <sarcasm> An even worse misuse, exiting the function from random locations avoiding logic completion </sarcasm> David Rob Wilkens wrote: > error = -EINVAL; > if (length < 0) /* sorry, but loff_t says... */ >- goto out; >+ return error; > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+IeLc74cGT/9uvgsRAmVKAJ0eNNXPL9vjCdkoaSGo0V9ZCihdNQCgg5np WKKq3YLs+Iz3mbDynww2Zk0= =R9xZ -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: [OffTopic] [apology] any chance of 2.6.0-test*? 2003-01-12 21:49 ` David Ford @ 2003-01-13 19:22 ` Rob Wilkens 0 siblings, 0 replies; 173+ messages in thread From: Rob Wilkens @ 2003-01-13 19:22 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: robwilkens I'm still getting messages in my inbox about it, but I'm dropping this whole goto thread nonsense. Some people (ok, at least 4 on this thread) have accused me of being "an arrogant beginner" (some by private e-mail, some with less friendly words but with the same basic meaning).. (about 2 or 3 others told me "not to leave" but rather to "tone down") I must apologize, but also comment that arrogance is not my intention. It's a de facto symptom of a biological illness I have. I hope you wouldn't hold it against me. I am taking medications to control it (maybe not so succssfully, but I'm up to 14 pills a day now), and apologize when it gets in the way of the normal flow of discussions here. It (The symptom in question) is called "Grandiosity" or "Inflated Sense of Self Worth" depending on the reference but here's some places where you can find the symptoms listed: http://bipolar.about.com/library/weekly/aa980408.htm Refers to "Grandiose Thinking", "Inflated Self Esteem", and something others may have seen on thist list, "Lack of insight"... http://www.frii.com/~parrot/dsm.html Refers more officially to "inflated self-esteem or grandiosity", and is listed as the first symptom under "mania" I'd suggest reading to educate yourself on the fact that you should no more make fun of me for being grandiose than you should make fun of a retarded person for being slow. It's a legitimate disabiliity, and I can actually collect social secutiy for it (and might go that route, it pays around $1500/month to stay home). Anyway, my point is that if I seem all that high and mighty in my tone, I'm not really that way in general (I'm really a nice guy). I don't know how to communicate that effectively, and I don't know that it matters. I also thank those who have pointed out the arrogance in my tone if indeed it was there. I have a therapist appointment in three hours and will definitely bring it up. Please do _not_ respond to this message on the list -- or if you do, don't quote it, it's off topic. I just wanted to generally send an apology to the few people who haven't already filterred me out as a result of my behavior. -Rob p.s. If I've gotten "black listed" (filtered,. procmailed, etc) so quickly by so many on this list so quickly, can you imagine how quickly I've probably (before even getting on this list) I've been blacklisted in the job market by former employers based on my behaviors there prior to quitting (they could not fire me for same behaviors due to the americans with disabilities act). A friend of mine claims he's seen my name on a corporate blacklist. I didn't ask for proof, but presumed he was right. It's only fair that social security exists to protect people like me from becoming completely homeless, and that they offer section 8 housing for mentally ill folk like myself whch one day (after my parents grow old and die) I will probably have to take advantage of.. p.p.s. I'm writing from window now as anyone looking at headers might figure out.. I know, "bad".. But I'm spending about 80% of my time in linux and 20% in windows which I think is fair. The thought of apologizing came to me now, and I happenned to have been in windows, so this is where I'm writing from. ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 21:27 ` Rob Wilkens 2003-01-12 21:40 ` Rik van Riel 2003-01-12 21:49 ` David Ford @ 2003-01-12 21:59 ` Adam Kropelin 2003-01-12 22:21 ` Rob Wilkens 2003-01-13 4:37 ` Billy Rose 2003-01-12 22:06 ` Oliver Neukum ` (4 subsequent siblings) 7 siblings, 2 replies; 173+ messages in thread From: Adam Kropelin @ 2003-01-12 21:59 UTC (permalink / raw) To: Rob Wilkens; +Cc: Matti Aarnio, Linux Kernel Mailing List On Sun, Jan 12, 2003 at 04:27:30PM -0500, Rob Wilkens wrote: > On Sun, 2003-01-12 at 16:15, Matti Aarnio wrote: > > On Sun, Jan 12, 2003 at 02:34:54PM -0500, Rob Wilkens wrote: > > > Linus, > > > > > > I'm REALLY opposed to the use of the word "goto" in any code where it's > > > not needed. OF course, I'm a linux kernel newbie, so I'm in no position > > > to comment > > > > fs/open.c file do_sys_truncate() function. > > > > Explain how you can do that cleanly, understandably, and without > > code duplication, or ugly kludges without using those goto ? > > (And sticking to coding-style.) > > I've only compiled (and haven't tested this code), but it should be much > faster than the original code. Why? Because we're eliminating an extra > "jump" in several places in the code every time open would be called. Congratulations. You've possibly increased the speed of an error path by an infintessimal amount at the expense of increasing the size of kernel image and making the code harder to read and maintain. (I say "possibly" since with caching effects you may have actually slowed the code down.) Harder to read: The primary code path is polluted with repetative code that has no bearing on its primary mission. Harder to maintain: Add an extra resource allocation near the top and now you have to hunt out every failure case and manually update them all (with yet more duplicate code) instead of just amending the cleanup code at the end of the function. > error = -EINVAL; > if (length < 0) /* sorry, but loff_t says... */ > - goto out; > + return error; Possibly an improvement, though there are maintenance and consistency arguments against it. > /* For directories it's -EISDIR, for other non-regulars - -EINVAL */ > error = -EISDIR; > - if (S_ISDIR(inode->i_mode)) > - goto dput_and_out; > + if (S_ISDIR(inode->i_mode)){ > + path_release(&nd); > + return error; > + } Nope. This code is precisely what the on-error-goto method is used to avoid. The use of goto in the kernel surprised me the first time I saw it, too. However, rather than hurry to point out how much more I knew about C style than the kernel hackers, I stayed quiet and made a learning experience of it. I suggest you do the same. --Adam ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 21:59 ` Adam Kropelin @ 2003-01-12 22:21 ` Rob Wilkens 2003-01-12 22:33 ` Tomas Szepe ` (4 more replies) 2003-01-13 4:37 ` Billy Rose 1 sibling, 5 replies; 173+ messages in thread From: Rob Wilkens @ 2003-01-12 22:21 UTC (permalink / raw) To: Adam Kropelin; +Cc: Matti Aarnio, Linux Kernel Mailing List On Sun, 2003-01-12 at 16:59, Adam Kropelin wrote: > Congratulations. You've possibly increased the speed of an error path by > an infintessimal amount at the expense of increasing the size of kernel > image and making the code harder to read and maintain. (I say "possibly" > since with caching effects you may have actually slowed the code down.) Hey, if the compiler does it's job right, I increased the speed of something in the kernel. And, as a kernel newbie, I'm proud of that. I also did it in under 12 minutes (from time stamp of message received to time stamp of message sent after code compiled and diff'd). > Harder to read: The primary code path is polluted with repetative code > that has no bearing on its primary mission. I thought it was easier to read. For me, I can read "ok, this condition happens, I fail"... Or "if this other condition happens, I release my path, then I fail"... Whereas the "goto out" was very unclear. It made me page down to figure out what was going on. That's the whole point.. To just browse the code.. I shouldn't have to page down to understand what the code right in front of me is doing. "goto out" is unclear. "retun error" is clear. "path_release" seems like a relatively plain english function name and I can guess what it does without knowing exactly what it does. I can also surmise that if I go beyond a certain point in the function that I need to path_release() the same way a non-kernel programmer might need to free memory allocated inside of a function before returning to the calling function. It really is that simple. > Harder to maintain: Add an extra resource allocation near the top and > now you have to hunt out every failure case and manually update them all > (with yet more duplicate code) instead of just amending the cleanup code > at the end of the function. It took me 12 minutes from message received to message sent to update the entire block of code to handle the new case. How long do you think it would take to make a minor modification that would only have to do a portion of what I did? Is it such a burden on the developer to make the code more readable? -Rob ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 22:21 ` Rob Wilkens @ 2003-01-12 22:33 ` Tomas Szepe 2003-01-12 22:36 ` Emiliano Gabrielli ` (3 subsequent siblings) 4 siblings, 0 replies; 173+ messages in thread From: Tomas Szepe @ 2003-01-12 22:33 UTC (permalink / raw) To: Adam Kropelin; +Cc: Matti Aarnio, Linux Kernel Mailing List > [robw@optonline.net] > > That's the whole point.. To just browse the code.. I shouldn't have to > page down to understand what the code right in front of me is doing. > "goto out" is unclear. "retun error" is clear. "path_release" seems > like a relatively plain english function name and I can guess what it > does without knowing exactly what it does. I can also surmise that if I > go beyond a certain point in the function that I need to path_release() > the same way a non-kernel programmer might need to free memory allocated > inside of a function before returning to the calling function. > > It really is that simple. "Never argue with an idiot. They drag you down to their level, then beat you with experience." -- Martin Josefsson T. ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 22:21 ` Rob Wilkens 2003-01-12 22:33 ` Tomas Szepe @ 2003-01-12 22:36 ` Emiliano Gabrielli 2003-01-12 22:38 ` Oliver Neukum ` (2 subsequent siblings) 4 siblings, 0 replies; 173+ messages in thread From: Emiliano Gabrielli @ 2003-01-12 22:36 UTC (permalink / raw) To: robw; +Cc: akropel1, matti.aarnio, linux-kernel <quote who="Rob Wilkens"> > On Sun, 2003-01-12 at 16:59, Adam Kropelin wrote: >> Congratulations. You've possibly increased the speed of an error path by an >> infintessimal amount at the expense of increasing the size of kernel image and >> making the code harder to read and maintain. (I say "possibly" since with caching >> effects you may have actually slowed the code down.) > > Hey, if the compiler does it's job right, I increased the speed of something in the > kernel. And, as a kernel newbie, I'm proud of that. I also did it in under 12 > minutes (from time stamp of message received to time stamp of message sent after code > compiled and diff'd). > >> Harder to read: The primary code path is polluted with repetative code that has no >> bearing on its primary mission. > > I thought it was easier to read. For me, I can read "ok, this condition happens, I > fail"... Or "if this other condition happens, I release my path, then I fail"... > > Whereas the "goto out" was very unclear. It made me page down to figure out what was > going on. > > That's the whole point.. To just browse the code.. I shouldn't have to page down to > understand what the code right in front of me is doing. "goto out" is unclear. > "retun error" is clear. "path_release" seems like a relatively plain english function > name and I can guess what it does without knowing exactly what it does. goto out_path_release is finer to you ?!? :) > I can also > surmise that if I go beyond a certain point in the function that I need to > path_release() the same way a non-kernel programmer might need to free memory > allocated inside of a function before returning to the calling function. > > It really is that simple. > >> Harder to maintain: Add an extra resource allocation near the top and now you have >> to hunt out every failure case and manually update them all (with yet more duplicate >> code) instead of just amending the cleanup code at the end of the function. > > It took me 12 minutes from message received to message sent to update the entire block > of code to handle the new case. How long do you think it would take to make a minor > modification that would only have to do a portion of what I did? Is it such a burden > on the developer to make the code more readable? > I think you have no idea of the mole of the linux kernel and the number of daily patches the mantainers receive ... I'm also a beginner, and me too at the very first time hated the goto (every one have told me they are evil !!) but after aving taken a look at the kernel and reading LinuxDevice Driver I think that the style the linux kernel is coded is cryptic for beginners, but it is perfect ! It is a wonderful experience to browse the linux kernel sources .. and every time I didn't understand why a thing was done in such a way .. well I discover later (with experience) that it was done in the best way it could ever be done !!! -- Emiliano Gabrielli dip. di Fisica 2° Università di Roma "Tor Vergata" ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 22:21 ` Rob Wilkens 2003-01-12 22:33 ` Tomas Szepe 2003-01-12 22:36 ` Emiliano Gabrielli @ 2003-01-12 22:38 ` Oliver Neukum 2003-01-12 22:42 ` romieu 2003-01-13 1:06 ` Randy Dunlap 4 siblings, 0 replies; 173+ messages in thread From: Oliver Neukum @ 2003-01-12 22:38 UTC (permalink / raw) To: robw; +Cc: Linux Kernel Mailing List Am Sonntag, 12. Januar 2003 23:21 schrieb Rob Wilkens: > On Sun, 2003-01-12 at 16:59, Adam Kropelin wrote: > > Congratulations. You've possibly increased the speed of an error path by > > an infintessimal amount at the expense of increasing the size of kernel > > image and making the code harder to read and maintain. (I say "possibly" > > since with caching effects you may have actually slowed the code down.) > > Hey, if the compiler does it's job right, I increased the speed of > something in the kernel. And, as a kernel newbie, I'm proud of that. I > also did it in under 12 minutes (from time stamp of message received to > time stamp of message sent after code compiled and diff'd). Nope you didn't. Any compiler that can move outline code like if (con) { cleanup() return err; } can easily simplify if (con) goto err_out; into a single branch. Still you have enlarged the kernel a bit. With the same number of jumps, as a rule of thumb, the smaller code is faster. Regards Oliver ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 22:21 ` Rob Wilkens ` (2 preceding siblings ...) 2003-01-12 22:38 ` Oliver Neukum @ 2003-01-12 22:42 ` romieu 2003-01-13 1:06 ` Randy Dunlap 4 siblings, 0 replies; 173+ messages in thread From: romieu @ 2003-01-12 22:42 UTC (permalink / raw) To: Rob Wilkens; +Cc: Linux Kernel Mailing List Rob Wilkens <robw@optonline.net> : [...] > It took me 12 minutes from message received to message sent to update > the entire block of code to handle the new case. How long do you think > it would take to make a minor modification that would only have to do a > portion of what I did? Is it such a burden on the developer to make the > code more readable? Herbal colon cleanser doesn't count as an efficient drug for linux kernel code programming. -- Ueimor ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 22:21 ` Rob Wilkens ` (3 preceding siblings ...) 2003-01-12 22:42 ` romieu @ 2003-01-13 1:06 ` Randy Dunlap 2003-01-13 1:21 ` Rob Wilkens 4 siblings, 1 reply; 173+ messages in thread From: Randy Dunlap @ 2003-01-13 1:06 UTC (permalink / raw) To: robw; +Cc: akropel1, matti.aarnio, linux-kernel >> Harder to read: The primary code path is polluted with repetative code >> that has no bearing on its primary mission. > > I thought it was easier to read. For me, I can read "ok, this condition > happens, I fail"... Or "if this other condition happens, I release my path, > then I fail"... over and over, with additions each time? > Whereas the "goto out" was very unclear. It made me page down to figure out > what was going on. > > That's the whole point.. To just browse the code.. I shouldn't have to page > down to understand what the code right in front of me is doing. "goto out" > is unclear. "retun error" is clear. "path_release" seems like a relatively > plain english function name and I can guess what it does without knowing > exactly what it does. I can also surmise that if I go beyond a certain > point in the function that I need to path_release() the same way a > non-kernel programmer might need to free memory allocated inside of a > function before returning to the calling function. So you choose to agree with your lessons that goto is bad, but ignore the other lesson that functions shouldn't have multiple return paths? Or didn't have that lesson? ~Randy ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 1:06 ` Randy Dunlap @ 2003-01-13 1:21 ` Rob Wilkens 2003-01-13 1:51 ` Nuno Monteiro 2003-01-13 3:48 ` Ryan Anderson 0 siblings, 2 replies; 173+ messages in thread From: Rob Wilkens @ 2003-01-13 1:21 UTC (permalink / raw) To: Randy Dunlap; +Cc: akropel1, matti.aarnio, linux-kernel On Sun, 2003-01-12 at 20:06, Randy Dunlap wrote: > So you choose to agree with your lessons that goto is bad, but > ignore the other lesson that functions shouldn't have multiple > return paths? Or didn't have that lesson? > ~Randy I didn't have a lesson about multiple return paths.. I actually before posting checked out the coding style document.. :/usr/src/linux-2.5.56/Documentation# grep -i return CodingStyle Returned nothing.. There was no mention of using return in the middle or end of a function in the coding style document, though perhaps there should be. -Rob ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 1:21 ` Rob Wilkens @ 2003-01-13 1:51 ` Nuno Monteiro 2003-01-13 2:19 ` Rob Wilkens 2003-01-13 3:48 ` Ryan Anderson 1 sibling, 1 reply; 173+ messages in thread From: Nuno Monteiro @ 2003-01-13 1:51 UTC (permalink / raw) To: linux-kernel On 13.01.03 01:21 Rob Wilkens wrote: > > I didn't have a lesson about multiple return paths.. I actually before > posting checked out the coding style document.. > > :/usr/src/linux-2.5.56/Documentation# grep -i return CodingStyle > > Returned nothing.. There was no mention of using return in the middle > or end of a function in the coding style document, though perhaps there > should be. > You dont realistically expect to learn how to program reading Documentation/CodingStyle, do you? CodingStyle merely serves as general guidelines of what is considered good practice among kernel development, no more no less. If you dont know how to code in the first place (which you have proved spectacularly, by now), you're SOL. Go educate yourself and stop trolling. Somewhere, along the bucketloads of vomit you insisted in throwing here, you asked who were the other top-rank trolls -- sincerely, and as far as I can remember, you're ahead by a fair margin. Not even imel96@trustix.co.id with his delireous "single user linux" crap came anywhere near you, although he was, too, very resistant to being clued in. See things from this end -- when 99% of the people tell you you're wrong, consider the possibility you are _actually_ wrong, and not the other way around. Now, off to ~/.killfile you go. Regards, Nuno ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 1:51 ` Nuno Monteiro @ 2003-01-13 2:19 ` Rob Wilkens 2003-01-13 2:51 ` Marcelo Pacheco ` (2 more replies) 0 siblings, 3 replies; 173+ messages in thread From: Rob Wilkens @ 2003-01-13 2:19 UTC (permalink / raw) To: Nuno Monteiro; +Cc: linux-kernel On Sun, 2003-01-12 at 20:51, Nuno Monteiro wrote: > You dont realistically expect to learn how to program reading > Documentation/CodingStyle, do you? CodingStyle merely serves as general No, but I would expect rules of kernel coding to be in there. For example, we were talking about using return mid-function. I always considerred that perfectly OK. Others were saying that's a no-no. If it's a no-no, it should be documented. That is, if it's a no-no. That may be a situational thing though. > See things from this end -- when 99% of the people tell you you're wrong, > consider the possibility you are _actually_ wrong, and not the other way > around. 99% of the people are running a microsoft based OS (It has 95% of the market in terms of sales, but factor in pirated copies and your figure will get close), of the 0.5% running linux, 0.025% of them are probably subscribed to this mailing list. Of that, probably 5% read it regularly. Now, of those 5% (of 0.25% of 0.5%), I'm probably getting 5-10 people reacting negatively (the rest are neutral reactions or no reactions), and claiming to speak (in a rather -- shall we say -- arrogant and self-important manor) for the list as a whole. > Now, off to ~/.killfile you go. Yeah, yeah, should've done it before.. -Rob p.s. Yes, all statistics are made up on the spot for comical purposes only and are only half-way intended to represent the real world. p.p.s. given those percentages, 5-10 people may be a lot percentagewise, I don't know, I haven't done the math. ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 2:19 ` Rob Wilkens @ 2003-01-13 2:51 ` Marcelo Pacheco 2003-01-13 3:37 ` Rob Wilkens 2003-01-13 4:53 ` Billy Rose 2003-01-13 3:06 ` Jochen Striepe 2003-01-13 9:45 ` Matti Aarnio 2 siblings, 2 replies; 173+ messages in thread From: Marcelo Pacheco @ 2003-01-13 2:51 UTC (permalink / raw) To: robw; +Cc: linux-kernel > > >99% of the people are running a microsoft based OS (It has 95% of the >market in terms of sales, but factor in pirated copies and your figure >will get close), of the 0.5% running linux, 0.025% of them are probably >subscribed to this mailing list. Of that, probably 5% read it >regularly. Now, of those 5% (of 0.25% of 0.5%), I'm probably getting >5-10 people reacting negatively (the rest are neutral reactions or no >reactions), and claiming to speak (in a rather -- shall we say -- >arrogant and self-important manor) for the list as a whole. > No Rob, most people don't bother responding because they read the FAQ for the list and they realize that this is waste of bandwidth of a lot of people that are important to Linux. You're wasting their times and this is why this should stop NOW. You're soo arrogant you don't want to see how much YOU'RE wrong ? See, I'm a computer geek that started at 11, that learned everything from the practical viewpoint (first assembly then Basic then structured language) and even going through structured programming classes 7 years latter they still managed to get brainwashed to the point that just now I realize that goto's are really a good thing, and that it should be used as standard practice (college has been 10+ years ago). So open your mind to the fact that you were brainwashed, and the fact that they brainwash so many people that aren't smart enough to question them, that everything is taken at face value. And Linux is not a hobbist thing anymore. From the point a lot of people trust their businesses to Linux like I do everyday (I'm MIS with about 12 Penguins, with about 30 more Microshits to be converted to Penguins), then you should respect people here. Me and I'm sure a lot others read this list daily, and they don't want to spend their time on this thread. I apreciate very much the work of everybody here, considering that they could probably make a hell of a lot more money through other ways, but they decided to go the open source way, and the whole world's society is benefiting from their work, instead of mostly benefiting big, greedy companies like microshit. By the way, you're not being paid my Microshit or other companies that have a lot to benefit from stalling Linux development to troll this list, aren't you ? Marcelo Pacheco ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 2:51 ` Marcelo Pacheco @ 2003-01-13 3:37 ` Rob Wilkens 2003-01-13 4:53 ` Billy Rose 1 sibling, 0 replies; 173+ messages in thread From: Rob Wilkens @ 2003-01-13 3:37 UTC (permalink / raw) To: Marcelo Pacheco; +Cc: linux-kernel On Sun, 2003-01-12 at 21:51, Marcelo Pacheco wrote: > No Rob, most people don't bother responding because they read the FAQ > for the list and they realize that this is waste of bandwidth of a lot > of people that are important to Linux. You're wasting their times and > this is why this should stop NOW. Actually, we were talking in private e-mail, so if we were discussing the FAQ, you would've continued this there, but since you've decided to bring this discussion out here, I'll continue it here for now.. I have unlimitted bandwidth, as do many others. IF they don't they shouldn't subscribe to this list, they should subscribe to the newsgroup and pick-and-choose by sbject/thread. > You're soo arrogant you don't want to see how much YOU'RE wrong ? I'm perfectly willing to see how much I'm wrong. No one has yet shown me that I'm wrong, though. I'd be perfectly willing to see it if it were shown. > See, I'm a computer geek that started at 11, that learned everything I have a head start on you then, I started around age 8. TI-99/4A & the BASIC programming language back then (I even had a voice box for the computer so I was writing programs that could talk which I thought was the coolest thing.) Moved on to the Commodore 64, 128, then moved into the PC world kind of late, in 1990 I bought an XT 10MHz machine that happenned to work with the commodore 128 monitor, and since then have incrementally upgrade part by part to my current machine (haven't upgraded in three years). > mind to the fact that you were brainwashed, and the fact that they > brainwash so many people that aren't smart enough to question them, that > everything is taken at face value. If I'm questioning people on this list, what makes you think I wasn't smart enough to question them then?? Think about that one for a second? > And Linux is not a hobbist thing anymore. From the point a lot of people > trust their businesses to Linux like I do everyday (I'm MIS with about > 12 Penguins, with about 30 more Microshits to be converted to Penguins), Serverwise or backofficewise, penguins have their place. On the desktop, penguins have to learn to adapt to a different climate. That's off topic for the kernel list though. > then you should respect people here. Me and I'm sure a lot others read > this list daily, and they don't want to spend their time on this thread. Then don't read it, skip over to the next message and move on with life. As someone else put it, life is too short. > I apreciate very much the work of everybody here, considering that they > could probably make a hell of a lot more money through other ways, but > they decided to go the open source way, and the whole world's society is > benefiting from their work, instead of mostly benefiting big, greedy > companies like microshit. Few would be doing it if there weren't SOME benefit for themselves. That benefit _may_ be a better system for themselves.. Some may be the intellectual satisfaction of a job well done.. Some may work for companies like red hat or suse.. Some may work for companies that want to replace old UNIX systems with cheaper PC hardware that does the same thing... Everyone has a motivating factor. > By the way, you're not being paid my Microshit or other companies that > have a lot to benefit from stalling Linux development to troll this > list, aren't you ? The answer to this is that I'm not in any way shape or form employed by any company what so ever at present. I'm considering part time work, but will not say more about that because the last time I mentioned something about an employer on a list where people thought I was a troll (alt.support.depression.manic around 2000 when I was unmedicated) they were sending faxes and calling the office where I worked at with complaints. I'd rather not forewarn any employer that I'm a little off-center, though I guess it wouldn't hurt my chances of eventually getting on social security disability which would cover my bills. -Rob ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 2:51 ` Marcelo Pacheco 2003-01-13 3:37 ` Rob Wilkens @ 2003-01-13 4:53 ` Billy Rose 1 sibling, 0 replies; 173+ messages in thread From: Billy Rose @ 2003-01-13 4:53 UTC (permalink / raw) To: Marcelo Pacheco; +Cc: robw, linux-kernel At 12:51 AM 1/13/2003 -0200, Marcelo Pacheco wrote: >And Linux is not a hobbist thing anymore. From the point a lot of people >trust their businesses to Linux like I do everyday (I'm MIS with about 12 >Penguins, with about 30 more Microshits to be converted to Penguins), then >you should respect people here. Me and I'm sure 20,000+ boxes here brother. constructive argument helps to drive innovation. this list was founded upon it, was it not? br ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 2:19 ` Rob Wilkens 2003-01-13 2:51 ` Marcelo Pacheco @ 2003-01-13 3:06 ` Jochen Striepe 2003-01-13 3:40 ` Rob Wilkens 2003-01-13 9:45 ` Matti Aarnio 2 siblings, 1 reply; 173+ messages in thread From: Jochen Striepe @ 2003-01-13 3:06 UTC (permalink / raw) To: linux-kernel Hi, On 12 Jan 2003, Rob Wilkens wrote: > > [...] Now, of those 5% (of 0.25% of 0.5%), I'm probably getting > 5-10 people reacting negatively (the rest are neutral reactions or no > reactions), [...] You don't think people might be silent because they think everything relevant was said by those 5-10 people? Please do assume long-time kernel hackers *know* what they do. Asking of course is OK, but please do not consider anything they do plain wrong just because you don't understand after some seconds of thinking. If you imply they're too dumb to do their job, you *will* get negative reactions, like it or not. If you think there's not enough documentation, try the web (including the mailing list archive) or some kernel hacking books. If some things are *not* documented at all (that is, you don't find the proper documentation), ask and write some documentation yourself or ask yourself were to get a grip on techniques your not familiar with. Thanks, Jochen. -- The sequence is important. People just learning to pee sometimes put the steps in the wrong order, with frustrating results. Maybe a checklist would be useful to those just starting out. -- Brien K. Meehan; Msg-ID <tkolgcfimtn387@news.supernews.com> ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 3:06 ` Jochen Striepe @ 2003-01-13 3:40 ` Rob Wilkens 0 siblings, 0 replies; 173+ messages in thread From: Rob Wilkens @ 2003-01-13 3:40 UTC (permalink / raw) To: Jochen Striepe; +Cc: linux-kernel On Sun, 2003-01-12 at 22:06, Jochen Striepe wrote: > If you imply they're too dumb to do their job, you *will* get negative > reactions, like it or not. I never implied anyone was too dumb to do their jobs. IF that was read into in any of my messages, I apologize. -Rob ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 2:19 ` Rob Wilkens 2003-01-13 2:51 ` Marcelo Pacheco 2003-01-13 3:06 ` Jochen Striepe @ 2003-01-13 9:45 ` Matti Aarnio 2 siblings, 0 replies; 173+ messages in thread From: Matti Aarnio @ 2003-01-13 9:45 UTC (permalink / raw) To: Rob Wilkens; +Cc: linux-kernel On Sun, Jan 12, 2003 at 09:19:28PM -0500, Rob Wilkens wrote: > On Sun, 2003-01-12 at 20:51, Nuno Monteiro wrote: > > You dont realistically expect to learn how to program reading > > Documentation/CodingStyle, do you? CodingStyle merely serves as general > > No, but I would expect rules of kernel coding to be in there. For > example, we were talking about using return mid-function. I always > considerred that perfectly OK. Others were saying that's a no-no. If > it's a no-no, it should be documented. That is, if it's a no-no. That > may be a situational thing though. That document is short for several reasons. - It has been written for particular needs, and updated rarely - Most long-time kernel coders really don't need detailed guidelines, although newcomers (like yourself) apparently want something.. Things you need to understand include at least: - Linux kernel is one of the most complicated codes that gcc compiler is ever put to work on, and over the years we have unearthed tons of optimizer bugs. Many of somewhat odd looking coding details do originate from circumventions of those compiler bugs. - Advanced optimizer hinting features, like unlikely() attribute are very new in (this) compiler, and while they in theory move the "unlikely" codes out of the fast-path, such things have been buggy in the past, and we are worried of bug effects... - Why code in a manner, where the optimizer needs to work very hard to produce fast code, when simplified structures, like those with 'goto' in them, can result the same with much less effort ? - Knowing effects of those optimizations requires profiling, and studying produced assembly code on different target systems. - Linux is multi-CPU-architecture kernel, looking at it via "intel-only, lattest Pentium-XIV" viewpoint is not going to cover all cases. Making changes that bloat code will make system that much harder to fit into smaller embedded machines. - Sometimes you need to code differently to achieve higher performance at different processors. See drivers/md/xor.c and header files it includes. Especially all include/asm-*/xor.h files, including include/asm-generic/xor.h ... (That shows to you how different approaches work at different systems. What works fast in register- rich processors does not necessarily be fast in register-poor things, like i386 series.) - Adding function classifiers like "static inline" do change rules somewhat. (Especially things like "mid-function return".) - Larger code, either with manually replicated exit cleanup (which are pain to maintain, when some large-scale change is needed), or via excessive use of "static inline", will pressure caches, and makes it more likely to drop soon to be again needed code (or data) from cache. Cases where cache-miss costs your tens, or hundreds of processor clock cycles that is really important question. - Explaining things like GCC asm() statement syntaxes isn't a thing for Linux kernel documentation. (Those vary from target processor to another!) I repeat: To understand effects of various coding details, you need to study produced assembly code, and keep in mind that in modern processors a branch out of straight-line execution path (after optimizations) is expensive (in time), and cache-misses are even more expensive. Then you need to benchmark those codes with different loads (where applicable) to find out what caches affect them -- and when you must bypass caches (they are limited resource, after all) in order to give overall improved system performance, when your code does not cause actively used code or data to be evicted from caches unnecessarily. > -Rob /Matti Aarnio ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 1:21 ` Rob Wilkens 2003-01-13 1:51 ` Nuno Monteiro @ 2003-01-13 3:48 ` Ryan Anderson 1 sibling, 0 replies; 173+ messages in thread From: Ryan Anderson @ 2003-01-13 3:48 UTC (permalink / raw) To: Linus Torvalds; +Cc: Rob Wilkens, linux-kernel On Sun, Jan 12, 2003 at 08:21:50PM -0500, Rob Wilkens wrote: > :/usr/src/linux-2.5.56/Documentation# grep -i return CodingStyle > > Returned nothing.. As annoying as this thread is, there are occassional valid points. A first pass at an addition: --- local/Documentation/CodingStyle.orig 2002-11-19 03:02:32.000000000 -0500 +++ local/Documentation/CodingStyle 2003-01-12 22:44:39.000000000 -0500 @@ -264,3 +264,27 @@ Remember: if another thread can find your data structure, and you don't have a reference count on it, you almost certainly have a bug. + + Chapter 9: Error handling + +Error handling in functions needs to follow a few simple rules. If the +function has allocated resources (irqs, memory), taken a reference, +grabbed locks, etc, all of those allocations must be reversed when +returning an error. + +In functions that depend on several allocations, the preferred way to +return the error is with with the use of a few "goto"s that point at an +error block at the end of the function, after the normal, successful +return. + +Several consecutive lables can be used, reversing the order of the +allocations. For example, if memory is allocated, a lock taken, and +an irq activated, the error labels might be labeled "err_noirq", +"err_nolock", "err_nomem", in order. The final step would be to +return the error. + +The reason for this style is very simple: Multiple return paths from +the same block of code are extremely confusing, and make verification +that locks are balanced, memory is properly freed, and that reference +counts are not leaked very difficult. + -- Ryan Anderson sometimes Pug Majere ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 21:59 ` Adam Kropelin 2003-01-12 22:21 ` Rob Wilkens @ 2003-01-13 4:37 ` Billy Rose 1 sibling, 0 replies; 173+ messages in thread From: Billy Rose @ 2003-01-13 4:37 UTC (permalink / raw) To: Adam Kropelin; +Cc: Rob Wilkens, Matti Aarnio, Linux Kernel Mailing List At 04:59 PM 1/12/2003 -0500, Adam Kropelin wrote: >The use of goto in the kernel surprised me the first time I saw it, too. >However, rather than hurry to point out how much more I knew about C >style than the kernel hackers, I stayed quiet and made a learning >experience of it. I suggest you do the same. > >--Adam every article i have read (an agreed with) on operating system internals, has stated that the goto is considered taboo in C... _except_ in operating system code where speed is critical, and goto can increase readability. i taught myself how to program by single stepping through assembly code on a DOS machine. i have found that too much structure leads not to modular code that is easy to maintain, but a nightmare of conditionals that cause your head to throb trying to trace the state of an execution. being that i am partial to assembly, perhaps i am biased in the matter. br ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 21:27 ` Rob Wilkens ` (2 preceding siblings ...) 2003-01-12 21:59 ` Adam Kropelin @ 2003-01-12 22:06 ` Oliver Neukum 2003-01-12 22:22 ` Rob Wilkens 2003-01-12 22:28 ` Matti Aarnio ` (3 subsequent siblings) 7 siblings, 1 reply; 173+ messages in thread From: Oliver Neukum @ 2003-01-12 22:06 UTC (permalink / raw) To: robw, Matti Aarnio; +Cc: Linux Kernel Mailing List > I've only compiled (and haven't tested this code), but it should be much > faster than the original code. Why? Because we're eliminating an extra > "jump" in several places in the code every time open would be called. > Yes, it's more code, so the kernel is a little bigger, but it should be > faster at the same time, and memory should be less of an issue nowadays. > > Here's the patch if you want to apply it (i have only compile tested it, > I haven't booted with it).. This patch applied to the 2.5.56 kernel. > > --- open.c.orig 2003-01-12 16:17:01.000000000 -0500 > +++ open.c 2003-01-12 16:22:32.000000000 -0500 > @@ -100,44 +100,58 @@ > > error = -EINVAL; > if (length < 0) /* sorry, but loff_t says... */ > - goto out; > + return error; Please don't do such things. The next time locking is changed and a lock is needed here, some poor guy has to go through that and change all back to goto. This may not be applicable here, but as a general rule, don't do it. I speak from experience. As for efficiency, that is the compiler's job. Regards Oliver ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 22:06 ` Oliver Neukum @ 2003-01-12 22:22 ` Rob Wilkens 2003-01-12 22:43 ` Oliver Neukum 2003-01-12 22:58 ` Robert Love 0 siblings, 2 replies; 173+ messages in thread From: Rob Wilkens @ 2003-01-12 22:22 UTC (permalink / raw) To: Oliver Neukum; +Cc: Matti Aarnio, Linux Kernel Mailing List On Sun, 2003-01-12 at 17:06, Oliver Neukum wrote: > Please don't do such things. The next time locking is changed and a lock > is needed here, some poor guy has to go through that and change all > back to goto. > This may not be applicable here, but as a general rule, don't do it. > I speak from experience. > > As for efficiency, that is the compiler's job. I say "please don't use goto" and instead have a "cleanup_lock" function and add that before all the return statements.. It should not be a burden. Yes, it's asking the developer to work a little harder, but the end result is better code. -Rob ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 22:22 ` Rob Wilkens @ 2003-01-12 22:43 ` Oliver Neukum 2003-01-12 22:51 ` Rob Wilkens 2003-01-12 22:58 ` Robert Love 1 sibling, 1 reply; 173+ messages in thread From: Oliver Neukum @ 2003-01-12 22:43 UTC (permalink / raw) To: robw; +Cc: Matti Aarnio, Linux Kernel Mailing List Am Sonntag, 12. Januar 2003 23:22 schrieb Rob Wilkens: > On Sun, 2003-01-12 at 17:06, Oliver Neukum wrote: > > Please don't do such things. The next time locking is changed and a lock > > is needed here, some poor guy has to go through that and change all > > back to goto. > > This may not be applicable here, but as a general rule, don't do it. > > I speak from experience. > > > > As for efficiency, that is the compiler's job. > > I say "please don't use goto" and instead have a "cleanup_lock" function > and add that before all the return statements.. It should not be a > burden. Yes, it's asking the developer to work a little harder, but the > end result is better code. It's code that causes added hardship for anybody checking the locking. It becomes impossible to see whether locks are balanced and turns into a nightmare as soon as you need error exits from several depths of locking or with and without memory to be freed. Please listen to experience. err_out_buffer: kfree(buffer); err_out_nobuffer: up(&sem); err_out_nolock: return err; is pretty much the only readable construction. Regards Oliver ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 22:43 ` Oliver Neukum @ 2003-01-12 22:51 ` Rob Wilkens 2003-01-12 23:00 ` Robert Love ` (3 more replies) 0 siblings, 4 replies; 173+ messages in thread From: Rob Wilkens @ 2003-01-12 22:51 UTC (permalink / raw) To: Oliver Neukum; +Cc: Matti Aarnio, Linux Kernel Mailing List On Sun, 2003-01-12 at 17:43, Oliver Neukum wrote: > It's code that causes added hardship for anybody checking the locking. I can certainly see where it would seem "easier" to match "one lock" to "one unlock" if your troubleshooting a locking issue. "easier" is the motivation behind using goto.. Laziness.. that's all it is. -Rob ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 22:51 ` Rob Wilkens @ 2003-01-12 23:00 ` Robert Love 2003-01-12 23:16 ` Rob Wilkens 2003-01-12 23:16 ` Nicolas Pitre 2003-01-12 23:05 ` Emiliano Gabrielli ` (2 subsequent siblings) 3 siblings, 2 replies; 173+ messages in thread From: Robert Love @ 2003-01-12 23:00 UTC (permalink / raw) To: robw; +Cc: Oliver Neukum, Matti Aarnio, Linux Kernel Mailing List On Sun, 2003-01-12 at 17:51, Rob Wilkens wrote: > "easier" is the motivation behind using goto.. Laziness.. that's > all it is. And faster, cleaner, simpler, and smaller. Yup. In the history of trolls on lkml, you are rising to the top. Are you proud? Robert Love ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 23:00 ` Robert Love @ 2003-01-12 23:16 ` Rob Wilkens 2003-01-12 23:16 ` Nicolas Pitre 1 sibling, 0 replies; 173+ messages in thread From: Rob Wilkens @ 2003-01-12 23:16 UTC (permalink / raw) To: Robert Love; +Cc: Oliver Neukum, Matti Aarnio, Linux Kernel Mailing List On Sun, 2003-01-12 at 18:00, Robert Love wrote: > In the history of trolls on lkml, you are rising to the top. Are you > proud? Let's see, I subscribed Thursday, it's now Sunday.. That's 3 or 4 days on the list.. I'm impressed if I've shot myself to the top of the entire troll list that quickly. Are there any other famous trolls to know about? :-) Does labelling or classifying someone as a troll make it any easier to dismiss what they're saying? -Rob ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 23:00 ` Robert Love 2003-01-12 23:16 ` Rob Wilkens @ 2003-01-12 23:16 ` Nicolas Pitre 1 sibling, 0 replies; 173+ messages in thread From: Nicolas Pitre @ 2003-01-12 23:16 UTC (permalink / raw) To: Robert Love; +Cc: Linux Kernel Mailing List On Sun, 12 Jan 2003, Robert Love wrote: > On Sun, 2003-01-12 at 17:51, Rob Wilkens wrote: > > > [...] > > And faster, cleaner, simpler, and smaller. Yup. > > In the history of trolls on lkml, you are rising to the top. Are you > proud? What amazes me the most is the ability this guy has to have people generate replies. Even Linus got caught. That's nearly better than RMS postings so far... Nicolas ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 22:51 ` Rob Wilkens 2003-01-12 23:00 ` Robert Love @ 2003-01-12 23:05 ` Emiliano Gabrielli 2003-01-12 23:23 ` Oliver Neukum 2003-01-12 23:16 ` Oliver Neukum 2003-01-13 2:00 ` Ryan Anderson 3 siblings, 1 reply; 173+ messages in thread From: Emiliano Gabrielli @ 2003-01-12 23:05 UTC (permalink / raw) To: robw; +Cc: oliver, matti.aarnio, linux-kernel <quote who="Rob Wilkens"> > On Sun, 2003-01-12 at 17:43, Oliver Neukum wrote: >> It's code that causes added hardship for anybody checking the locking. > > I can certainly see where it would seem "easier" to match "one lock" to "one unlock" > if your troubleshooting a locking issue. > > "easier" is the motivation behind using goto.. Laziness.. that's all it is. In italy we say "Non c'è peggior sordo di chi non vuole sentire" Till to this point the thread was useful to beginners becouse of a lot of smarty coders explained a point that everyone has heard but that rarely knows at deep... but now Let's ignore him ! He is not a beginner he is a lamer! -- Emiliano Gabrielli dip. di Fisica 2° Università di Roma "Tor Vergata" ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 23:05 ` Emiliano Gabrielli @ 2003-01-12 23:23 ` Oliver Neukum 2003-01-12 23:45 ` Emiliano Gabrielli ` (2 more replies) 0 siblings, 3 replies; 173+ messages in thread From: Oliver Neukum @ 2003-01-12 23:23 UTC (permalink / raw) To: Emiliano Gabrielli; +Cc: linux-kernel Am Montag, 13. Januar 2003 00:05 schrieb Emiliano Gabrielli: > <quote who="Rob Wilkens"> > > > On Sun, 2003-01-12 at 17:43, Oliver Neukum wrote: > >> It's code that causes added hardship for anybody checking the locking. > > > > I can certainly see where it would seem "easier" to match "one lock" to > > "one unlock" if your troubleshooting a locking issue. > > > > "easier" is the motivation behind using goto.. Laziness.. that's all it > > is. > > In italy we say "Non c'è peggior sordo di chi non vuole sentire" There's no worse fate than that of those who don't want to listen? (My Italian is bad.) > Till to this point the thread was useful to beginners becouse of a lot of > smarty coders explained a point that everyone has heard but that rarely > knows at deep... > > but now Let's ignore him ! He is not a beginner he is a lamer! Very well. What could be said has been said. But please don't insult him. Time spent explaining is usually well spent. Perhaps somebody learned. OK, maybe I have a soft spot. Regards Oliver ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 23:23 ` Oliver Neukum @ 2003-01-12 23:45 ` Emiliano Gabrielli 2003-01-12 23:45 ` Emiliano Gabrielli 2003-01-13 20:01 ` Horst von Brand 2 siblings, 0 replies; 173+ messages in thread From: Emiliano Gabrielli @ 2003-01-12 23:45 UTC (permalink / raw) To: oliver; +Cc: linux-kernel <quote who="Oliver Neukum"> > Am Montag, 13. Januar 2003 00:05 schrieb Emiliano Gabrielli: >> <quote who="Rob Wilkens"> >> >> > On Sun, 2003-01-12 at 17:43, Oliver Neukum wrote: >> >> It's code that causes added hardship for anybody checking the locking. >> > >> > I can certainly see where it would seem "easier" to match "one lock" to "one >> unlock" if your troubleshooting a locking issue. >> > >> > "easier" is the motivation behind using goto.. Laziness.. that's all it is. >> >> In italy we say "Non c'è peggior sordo di chi non vuole sentire" > > There's no worse fate than that of those who don't want to listen? (My Italian is > bad.) It is better than my english :-)) > >> Till to this point the thread was useful to beginners becouse of a lot of smarty >> coders explained a point that everyone has heard but that rarely knows at deep... >> >> but now Let's ignore him ! He is not a beginner he is a lamer! > > Very well. What could be said has been said. But please don't insult him. Time spent > explaining is usually well spent. Perhaps somebody learned. > I agree .. my apologises .. I use currently the word "lamer" in IRC, but I don't really know the true translation.. if it is an insult .. plz adcept my apologises > OK, maybe I have a soft spot. > :-) > Regards > Oliver -- Emiliano Gabrielli dip. di Fisica 2° Università di Roma "Tor Vergata" ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 23:23 ` Oliver Neukum 2003-01-12 23:45 ` Emiliano Gabrielli @ 2003-01-12 23:45 ` Emiliano Gabrielli 2003-01-13 20:01 ` Horst von Brand 2 siblings, 0 replies; 173+ messages in thread From: Emiliano Gabrielli @ 2003-01-12 23:45 UTC (permalink / raw) To: oliver; +Cc: linux-kernel <quote who="Oliver Neukum"> > Am Montag, 13. Januar 2003 00:05 schrieb Emiliano Gabrielli: >> <quote who="Rob Wilkens"> >> >> > On Sun, 2003-01-12 at 17:43, Oliver Neukum wrote: >> >> It's code that causes added hardship for anybody checking the locking. >> > >> > I can certainly see where it would seem "easier" to match "one lock" to "one >> unlock" if your troubleshooting a locking issue. >> > >> > "easier" is the motivation behind using goto.. Laziness.. that's all it is. >> >> In italy we say "Non c'è peggior sordo di chi non vuole sentire" > > There's no worse fate than that of those who don't want to listen? (My Italian is > bad.) It is better than my english :-)) > >> Till to this point the thread was useful to beginners becouse of a lot of smarty >> coders explained a point that everyone has heard but that rarely knows at deep... >> >> but now Let's ignore him ! He is not a beginner he is a lamer! > > Very well. What could be said has been said. But please don't insult him. Time spent > explaining is usually well spent. Perhaps somebody learned. > I agree .. my apologises .. I use currently the word "lamer" in IRC, but I don't really know the true translation.. if it is an insult .. plz adcept my apologises > OK, maybe I have a soft spot. > :-) > Regards > Oliver -- Emiliano Gabrielli dip. di Fisica 2° Università di Roma "Tor Vergata" ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 23:23 ` Oliver Neukum 2003-01-12 23:45 ` Emiliano Gabrielli 2003-01-12 23:45 ` Emiliano Gabrielli @ 2003-01-13 20:01 ` Horst von Brand 2 siblings, 0 replies; 173+ messages in thread From: Horst von Brand @ 2003-01-13 20:01 UTC (permalink / raw) To: Oliver Neukum; +Cc: linux-kernel [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 655 bytes --] Oliver Neukum <oliver@neukum.name> said: > Am Montag, 13. Januar 2003 00:05 schrieb Emiliano Gabrielli: [...] > > In italy we say "Non c'è peggior sordo di chi non vuole sentire" I guess in Chile it's "No hay peor sordo que el que no quiere oir". > There's no worse fate than that of those who don't want to listen? There is no worse deaf than the one who refuses to listen. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 22:51 ` Rob Wilkens 2003-01-12 23:00 ` Robert Love 2003-01-12 23:05 ` Emiliano Gabrielli @ 2003-01-12 23:16 ` Oliver Neukum 2003-01-13 2:00 ` Ryan Anderson 3 siblings, 0 replies; 173+ messages in thread From: Oliver Neukum @ 2003-01-12 23:16 UTC (permalink / raw) To: robw; +Cc: Linux Kernel Mailing List Am Sonntag, 12. Januar 2003 23:51 schrieb Rob Wilkens: > On Sun, 2003-01-12 at 17:43, Oliver Neukum wrote: > > It's code that causes added hardship for anybody checking the locking. > > I can certainly see where it would seem "easier" to match "one lock" to > "one unlock" if your troubleshooting a locking issue. > > "easier" is the motivation behind using goto.. Laziness.. that's all it > is. Yes, exactly. Lazyness is good. Any second spend on hitting Ctrl+F and typing in the name of a cleanup function is lost. Any time you overlook something because the cleanup and the code are not on the same screen is a bug that is overlooked. Any time one of the cleanup functions is overlooked can cause hours lost in debugging after a change. Oliver ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 22:51 ` Rob Wilkens ` (2 preceding siblings ...) 2003-01-12 23:16 ` Oliver Neukum @ 2003-01-13 2:00 ` Ryan Anderson 2003-01-13 3:09 ` Rob Wilkens 3 siblings, 1 reply; 173+ messages in thread From: Ryan Anderson @ 2003-01-13 2:00 UTC (permalink / raw) To: Linux Kernel Mailing List On Sun, Jan 12, 2003 at 05:51:57PM -0500, Rob Wilkens wrote: > On Sun, 2003-01-12 at 17:43, Oliver Neukum wrote: > > It's code that causes added hardship for anybody checking the locking. > > I can certainly see where it would seem "easier" to match "one lock" to > "one unlock" if your troubleshooting a locking issue. > > "easier" is the motivation behind using goto.. Laziness.. that's all it > is. Have you ever read "Programming Perl"? Laziness is a virtue. (At least I think that's the right book - possibly the 3rd edition.) -- Ryan Anderson sometimes Pug Majere ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 2:00 ` Ryan Anderson @ 2003-01-13 3:09 ` Rob Wilkens 2003-01-14 2:13 ` Rik van Riel 0 siblings, 1 reply; 173+ messages in thread From: Rob Wilkens @ 2003-01-13 3:09 UTC (permalink / raw) To: Ryan Anderson; +Cc: Linux Kernel Mailing List On Sun, 2003-01-12 at 21:00, Ryan Anderson wrote: > On Sun, Jan 12, 2003 at 05:51:57PM -0500, Rob Wilkens wrote: > > "easier" is the motivation behind using goto.. Laziness.. that's all it > > is. > > Have you ever read "Programming Perl"? > > Laziness is a virtue. (At least I think that's the right book - > possibly the 3rd edition.) Actually, it's one of the few books I actually still own (the perl one).. Laziness is indeed a virtue.. One I live my life by. Of course, that's why I haven't gotten off my ass all day and have been doing nothing but reading/writing mails from this list. :-0 If the list accepted binaries, I'd take a photo of my room and workspace, and you'd get the impression that I was one of the laziest people you've ever met. Granted, one of my computer science professors (not one of the greatest professors I ever had) said that the best programmers in the world are the laziest sons of bitches you'll ever meet, and I think I may qualify (as a lazy son of a bitch, not necessarily as a great programmer). Aww.. Heck.. Go ahead and use goto all you want. I'm not in a position to stop anyone anyway. -Rob ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 3:09 ` Rob Wilkens @ 2003-01-14 2:13 ` Rik van Riel 0 siblings, 0 replies; 173+ messages in thread From: Rik van Riel @ 2003-01-14 2:13 UTC (permalink / raw) To: Rob Wilkens; +Cc: Ryan Anderson, Linux Kernel Mailing List On Sun, 12 Jan 2003, Rob Wilkens wrote: > Granted, one of my computer science professors (not one of the greatest > professors I ever had) said that the best programmers in the world are > the laziest sons of bitches you'll ever meet, I think this is generally marketed under the term "code reuse" cheers, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://guru.conectiva.com/ Current spamtrap: <a href=mailto:"october@surriel.com">october@surriel.com</a> ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 22:22 ` Rob Wilkens 2003-01-12 22:43 ` Oliver Neukum @ 2003-01-12 22:58 ` Robert Love 1 sibling, 0 replies; 173+ messages in thread From: Robert Love @ 2003-01-12 22:58 UTC (permalink / raw) To: robw; +Cc: Oliver Neukum, Matti Aarnio, Linux Kernel Mailing List On Sun, 2003-01-12 at 17:22, Rob Wilkens wrote: > I say "please don't use goto" and instead have a "cleanup_lock" function > and add that before all the return statements.. It should not be a > burden. Yes, it's asking the developer to work a little harder, but the > end result is better code. No, it is gross and it bloats the kernel. It inlines a bunch of junk for N error paths, as opposed to having the exit code once at the end. Cache footprint is key and you just killed it. Nor is it easier to read. As a final argument, it does not let us cleanly do the usual stack-esque wind and unwind, i.e. do A if (error) goto out_a; do B if (error) goto out_b; do C if (error) goto out_c; goto out; out_c: undo C out_b: undo B: out_a: undo A out: return ret; Now stop this. Robert Love ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 21:27 ` Rob Wilkens ` (3 preceding siblings ...) 2003-01-12 22:06 ` Oliver Neukum @ 2003-01-12 22:28 ` Matti Aarnio 2003-01-13 1:26 ` David Lang ` (2 subsequent siblings) 7 siblings, 0 replies; 173+ messages in thread From: Matti Aarnio @ 2003-01-12 22:28 UTC (permalink / raw) To: Rob Wilkens; +Cc: Linux Kernel Mailing List On Sun, Jan 12, 2003 at 04:27:30PM -0500, Rob Wilkens wrote: > > Explain how you can do that cleanly, understandably, and without > > code duplication, or ugly kludges without using those goto ? > > (And sticking to coding-style.) > > I've only compiled (and haven't tested this code), but it should be much > faster than the original code. Why? Because we're eliminating an extra > "jump" in several places in the code every time open would be called. Benchmark them - original and your revised. (Their equivalents, that is, in userspace with rdtscll() ) Put them into a test-harness calling them million times (or some such). Look also what assembly the compiler produced, e.g. that it didn't optimize away error paths. > Yes, it's more code, so the kernel is a little bigger, but it should be > faster at the same time, and memory should be less of an issue nowadays. That is common fallacy. Learn to code in environments where you have to account for every byte of code and ram usage, and your code will be fast even in bigger systems. > Here's the patch if you want to apply it (i have only compile tested it, > I haven't booted with it).. This patch applied to the 2.5.56 kernel. .... /Matti Aarnio ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 21:27 ` Rob Wilkens ` (4 preceding siblings ...) 2003-01-12 22:28 ` Matti Aarnio @ 2003-01-13 1:26 ` David Lang 2003-01-13 2:00 ` William Lee Irwin III 2003-01-13 11:08 ` How to avoid the woord 'goto' (was Re: any chance of 2.6.0-test*?) Bernd Petrovitsch 2003-01-13 22:02 ` any chance of 2.6.0-test*? Val Henson 7 siblings, 1 reply; 173+ messages in thread From: David Lang @ 2003-01-13 1:26 UTC (permalink / raw) To: Rob Wilkens; +Cc: Matti Aarnio, Linux Kernel Mailing List > I've only compiled (and haven't tested this code), but it should be much > faster than the original code. Why? Because we're eliminating an extra > "jump" in several places in the code every time open would be called. > Yes, it's more code, so the kernel is a little bigger, but it should be > faster at the same time, and memory should be less of an issue nowadays. Rob, one thing you may not have noticed since you haven't been following the list for a while is that with the current generation of computers size frequently translates directly into speed and a lot of the time honored performance tricks that trade size for fewer commands executed end up being losses. this can be seen by compiling code with -O2 and with -Os and frequently the -Os will actually be faster. This is becouse not all memory is equal, main memory is very slow compared to the CPU cache, so code that is slightly larger can cause more cache misses and therefor be slower, even if significantly fewer commands are executed. in addition frequently the effect isn't direct (i.e. no noticable difference on the code you are changing, but instead the change makes other code slower as it gets evicted from the cache) unfortunantly while this effect is known the rules of when to optimize for space and when to optimize for fewer cpu cycles for code execution are not clear and vary from CPU to CPU frequently within variations of the same family) if you google for -Os you should find one of the several discussions on the list in the last year on the subject. David Lang ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 1:26 ` David Lang @ 2003-01-13 2:00 ` William Lee Irwin III 0 siblings, 0 replies; 173+ messages in thread From: William Lee Irwin III @ 2003-01-13 2:00 UTC (permalink / raw) To: David Lang; +Cc: Rob Wilkens, Matti Aarnio, Linux Kernel Mailing List On Sun, Jan 12, 2003 at 05:26:48PM -0800, David Lang wrote: > This is becouse not all memory is equal, main memory is very slow compared > to the CPU cache, so code that is slightly larger can cause more cache > misses and therefor be slower, even if significantly fewer commands are > executed. Not all memory is equal here, either i.e. I'm on NUMA boxen. Bill ^ permalink raw reply [flat|nested] 173+ messages in thread
* How to avoid the woord 'goto' (was Re: any chance of 2.6.0-test*?) 2003-01-12 21:27 ` Rob Wilkens ` (5 preceding siblings ...) 2003-01-13 1:26 ` David Lang @ 2003-01-13 11:08 ` Bernd Petrovitsch 2003-01-13 14:56 ` Rob Wilkens 2003-01-13 22:02 ` any chance of 2.6.0-test*? Val Henson 7 siblings, 1 reply; 173+ messages in thread From: Bernd Petrovitsch @ 2003-01-13 11:08 UTC (permalink / raw) To: Linux Kernel Mailing List Rob Wilkens <robw@optonline.net> wrote: [...] >Here's the patch if you want to apply it (i have only compile tested it, >I haven't booted with it).. This patch applied to the 2.5.56 kernel. > >--- open.c.orig 2003-01-12 16:17:01.000000000 -0500 >+++ open.c 2003-01-12 16:22:32.000000000 -0500 >@@ -100,44 +100,58 @@ > > error = -EINVAL; > if (length < 0) /* sorry, but loff_t says... */ >- goto out; >+ return error; > > error = user_path_walk(path, &nd); > if (error) >- goto out; >+ return error; > inode = nd.dentry->d_inode; [ snipped the rest ] You just copied the logic to "cleanup and leave" the function several times. The (current, next and subsequent) maintainers at the next change in that function simply _have_ to check all cases as if they are different. Yes, _now_ you (and all others) know that they are identical. But in 6 month after tons of patches? Perhaps you want to avoid goto's with: ---- snip (yes, it is purposely not a `diff -urN`) ---- switch(0==0) { default: error = -EINVAL; if (length < 0) /* sorry, but loff_t says... */ break; error = user_path_walk(path, &nd); if (error) break; inode = nd.dentry->d_inode; switch(0==0) { default: /* For directories it's -EISDIR, for other non-regulars - -EINVAL */ error = -EISDIR; if (S_ISDIR(inode->i_mode)) break; error = -EINVAL; if (!S_ISREG(inode->i_mode)) break; error = permission(inode,MAY_WRITE); if (error) break; error = -EROFS; if(IS_RDONLY(inode)) break; /* the rest omitted - the pattern should be clear */ put_write_access(inode); break; } path_release(&nd); break; } return error; ---- snip ---- FYI, backward goto's can be rewritten with: ---- snip ---- for(;;) { <do something> if(i_want_to_go_back) continue; <do something_else> break; } ---- snip ---- Are these two more understandable because the avoid the 'goto'? And try to see it not from the viewpoint of a first time reader, but from the viewpoint of a/the maintainer/developer (who reads this code probably quite often)? Bernd -- Bernd Petrovitsch Email : bernd@gams.at g.a.m.s gmbh Fax : +43 1 205255-900 Prinz-Eugen-Straße 8 A-1040 Vienna/Austria/Europe LUGA : http://www.luga.at ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: How to avoid the woord 'goto' (was Re: any chance of 2.6.0-test*?) 2003-01-13 11:08 ` How to avoid the woord 'goto' (was Re: any chance of 2.6.0-test*?) Bernd Petrovitsch @ 2003-01-13 14:56 ` Rob Wilkens 0 siblings, 0 replies; 173+ messages in thread From: Rob Wilkens @ 2003-01-13 14:56 UTC (permalink / raw) To: Bernd Petrovitsch; +Cc: Linux Kernel Mailing List Yeah, but.. My changes won't actually be incorporated (i hope) into the kernel. I've since learned that a goto will optimize to be just as quick as what I wrote (by studying the optimized assembler output at other suggestion). Therefore, it was silly and pointless for me to spend the 10-12 minutes I did changing the code and testing it and e-mailing back the changes. So, there's nothing to worry about. Goto's are here forever. -Rob On Mon, 2003-01-13 at 06:08, Bernd Petrovitsch wrote: > Rob Wilkens <robw@optonline.net> wrote: > [...] > >Here's the patch if you want to apply it (i have only compile tested it, > >I haven't booted with it).. This patch applied to the 2.5.56 kernel. > > > >--- open.c.orig 2003-01-12 16:17:01.000000000 -0500 > >+++ open.c 2003-01-12 16:22:32.000000000 -0500 > >@@ -100,44 +100,58 @@ > > > > error = -EINVAL; > > if (length < 0) /* sorry, but loff_t says... */ > >- goto out; > >+ return error; > > > > error = user_path_walk(path, &nd); > > if (error) > >- goto out; > >+ return error; > > inode = nd.dentry->d_inode; > [ snipped the rest ] > > You just copied the logic to "cleanup and leave" the function several > times. The (current, next and subsequent) maintainers at the next > change in that function simply _have_ to check all cases as if they > are different. > Yes, _now_ you (and all others) know that they are identical. But in 6 > month after tons of patches? > > Perhaps you want to avoid goto's with: > ---- snip (yes, it is purposely not a `diff -urN`) ---- > switch(0==0) { > default: > error = -EINVAL; > if (length < 0) /* sorry, but loff_t says... */ > break; > error = user_path_walk(path, &nd); > if (error) > break; > inode = nd.dentry->d_inode; > > switch(0==0) { > default: > /* For directories it's -EISDIR, for other non-regulars - -EINVAL */ > error = -EISDIR; > if (S_ISDIR(inode->i_mode)) > break; > error = -EINVAL; > if (!S_ISREG(inode->i_mode)) > break; > > error = permission(inode,MAY_WRITE); > if (error) > break; > > error = -EROFS; > if(IS_RDONLY(inode)) > break; > > /* the rest omitted - the pattern should be clear */ > > put_write_access(inode); > break; > } > path_release(&nd); > break; > } > return error; > ---- snip ---- > > FYI, backward goto's can be rewritten with: > ---- snip ---- > > for(;;) { > <do something> > if(i_want_to_go_back) > continue; > <do something_else> > break; > } > ---- snip ---- > > Are these two more understandable because the avoid the 'goto'? > And try to see it not from the viewpoint of a first time reader, but > from the viewpoint of a/the maintainer/developer (who reads this code > probably quite often)? > > Bernd ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 21:27 ` Rob Wilkens ` (6 preceding siblings ...) 2003-01-13 11:08 ` How to avoid the woord 'goto' (was Re: any chance of 2.6.0-test*?) Bernd Petrovitsch @ 2003-01-13 22:02 ` Val Henson 7 siblings, 0 replies; 173+ messages in thread From: Val Henson @ 2003-01-13 22:02 UTC (permalink / raw) To: Linux Kernel Mailing List On Sun, Jan 12, 2003 at 04:27:30PM -0500, Rob Wilkens wrote: > > I've only compiled (and haven't tested this code), but it should be much > faster than the original code. Why? Because we're eliminating an extra > "jump" in several places in the code every time open would be called. > Yes, it's more code, so the kernel is a little bigger, but it should be > faster at the same time, and memory should be less of an issue nowadays. To the tune of "Teen Angst" from Cracker: Cause, what the world needs now, is another theoretical optimizer like I need a hole in my head. You'd think I'd be resigned to the l-k tradition of the unbenchmarked "optimization" patch, but apparently not yet... -VAL ^ permalink raw reply [flat|nested] 173+ messages in thread
* gotos in kernel [Was: Re: any chance of 2.6.0-test*?] 2003-01-12 19:34 ` Rob Wilkens ` (4 preceding siblings ...) 2003-01-12 21:15 ` Matti Aarnio @ 2003-01-13 10:32 ` Horst von Brand 2003-01-13 14:53 ` Rob Wilkens 2003-01-13 13:08 ` any chance of 2.6.0-test*? Dave Jones 2003-01-13 15:23 ` Richard B. Johnson 7 siblings, 1 reply; 173+ messages in thread From: Horst von Brand @ 2003-01-13 10:32 UTC (permalink / raw) To: robw; +Cc: Linux Kernel Mailing List Rob Wilkens <robw@optonline.net> said: > I'm REALLY opposed to the use of the word "goto" in any code where it's > not needed. OF course, I'm a linux kernel newbie, so I'm in no position > to comment My, my, my, an anti-goto zealot now. > Let me comment below the relevant code snippet below as to how I would > change it: > > On Sun, 2003-01-12 at 14:15, Linus Torvalds wrote: > > if (spin_trylock(&tty_lock.lock)) > > goto got_lock; > > if (tsk == tty_lock.lock_owner) { > > WARN_ON(!tty_lock.lock_count); > > tty_lock.lock_count++; > > return flags; > > } > > spin_lock(&tty_lock.lock); > > got_lock: > > WARN_ON(tty_lock.lock_owner); > <etc...> > > I would change it to something like the following (without testing the > code through a compiler or anything to see if it's valid): It just to happens that sometimes the compiler generates stupid code for goto-less solutions. While the famous "no goto needed" theorem is certainly true, it duplicates lots of code to get rid of gotos, and that is a no - never - only over my dead body proposition in a kernel that tries to be as fast as humanly possible. And if used with care and good taste, a goto can lead to clearer, more understandable (and thus more probably correct) code. Just look up what sort of "programming style" Dijkstra was complaining about when asking to ban gotos, and what D. E. Knuth has to say on structured programming with gotos. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: gotos in kernel [Was: Re: any chance of 2.6.0-test*?] 2003-01-13 10:32 ` gotos in kernel [Was: Re: any chance of 2.6.0-test*?] Horst von Brand @ 2003-01-13 14:53 ` Rob Wilkens 0 siblings, 0 replies; 173+ messages in thread From: Rob Wilkens @ 2003-01-13 14:53 UTC (permalink / raw) To: Horst von Brand; +Cc: Linux Kernel Mailing List On Mon, 2003-01-13 at 05:32, Horst von Brand wrote: > Rob Wilkens <robw@optonline.net> said: > > I'm REALLY opposed to the use of the word "goto" in any code where it's > > not needed. OF course, I'm a linux kernel newbie, so I'm in no position > > to comment > > My, my, my, an anti-goto zealot now. I pick out _one_ piece of code that _one_ random person posts publicly (so, it happens to be one of the leaders of the free open source world) and suddenly I'm a zealot. I'm a nobody and proud of that fact. I was just explaining my dislike of a particular code structure based on my earlier training and experience. In the time since my writing of that post and your response, though, I have since been "Enlightenned" by all of the wonderful people on this discussion forum. -Rob ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 19:34 ` Rob Wilkens ` (5 preceding siblings ...) 2003-01-13 10:32 ` gotos in kernel [Was: Re: any chance of 2.6.0-test*?] Horst von Brand @ 2003-01-13 13:08 ` Dave Jones 2003-01-13 13:40 ` Andrew Walrond ` (2 more replies) 2003-01-13 15:23 ` Richard B. Johnson 7 siblings, 3 replies; 173+ messages in thread From: Dave Jones @ 2003-01-13 13:08 UTC (permalink / raw) To: Rob Wilkens Cc: Linus Torvalds, Christoph Hellwig, Greg KH, Alan Cox, William Lee Irwin III, Linux Kernel Mailing List On Sun, Jan 12, 2003 at 02:34:54PM -0500, Rob Wilkens wrote: > I'm REALLY opposed to the use of the word "goto" in any code where it's > not needed. OF course, I'm a linux kernel newbie, so I'm in no position > to comment Someone want to add this one to the lkml faq (does anyone actually read that these days?) or maybe http://www.kernelnewbies.org/faq/ Wow, one week later, and this would tie in with the fourth anniversary of someone else[2] making an ass of himself on this issue[1] Dave [1] http://www.uwsg.iu.edu/hypermail/linux/kernel/9901.2/0939.html [2] Complete with quaint 'cool' l33t handle. How 90s! *bows head in shame* -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 13:08 ` any chance of 2.6.0-test*? Dave Jones @ 2003-01-13 13:40 ` Andrew Walrond 2003-01-13 13:49 ` Oliver Neukum 2003-01-14 6:52 ` Bruce Harada 2 siblings, 0 replies; 173+ messages in thread From: Andrew Walrond @ 2003-01-13 13:40 UTC (permalink / raw) To: Dave Jones; +Cc: linux-kernel Well well. Who'd have thought! Idealistic youth; those were the days; etc etc ;) Dave Jones wrote: > On Sun, Jan 12, 2003 at 02:34:54PM -0500, Rob Wilkens wrote: > > > I'm REALLY opposed to the use of the word "goto" in any code where it's > > not needed. OF course, I'm a linux kernel newbie, so I'm in no position > > to comment > > Someone want to add this one to the lkml faq (does anyone actually > read that these days?) or maybe http://www.kernelnewbies.org/faq/ > > Wow, one week later, and this would tie in with the fourth anniversary > of someone else[2] making an ass of himself on this issue[1] > > Dave > > [1] http://www.uwsg.iu.edu/hypermail/linux/kernel/9901.2/0939.html > [2] Complete with quaint 'cool' l33t handle. How 90s! *bows head in shame* > ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 13:08 ` any chance of 2.6.0-test*? Dave Jones 2003-01-13 13:40 ` Andrew Walrond @ 2003-01-13 13:49 ` Oliver Neukum 2003-01-14 6:52 ` Bruce Harada 2 siblings, 0 replies; 173+ messages in thread From: Oliver Neukum @ 2003-01-13 13:49 UTC (permalink / raw) To: Dave Jones, Rob Wilkens Cc: Linus Torvalds, Christoph Hellwig, Greg KH, Alan Cox, William Lee Irwin III, Linux Kernel Mailing List Am Montag, 13. Januar 2003 14:08 schrieb Dave Jones: > On Sun, Jan 12, 2003 at 02:34:54PM -0500, Rob Wilkens wrote: > > I'm REALLY opposed to the use of the word "goto" in any code where it's > > not needed. OF course, I'm a linux kernel newbie, so I'm in no position > > to comment > > Someone want to add this one to the lkml faq (does anyone actually > read that these days?) or maybe http://www.kernelnewbies.org/faq/ > > Wow, one week later, and this would tie in with the fourth anniversary > of someone else[2] making an ass of himself on this issue[1] So let us rejoice in a story of human growth. In the exuberant spirit of this joyfull occasion, I'd like you to find a place for this memorative piece of code: if (a->sibling->present) goto your_place; else goto my_place; Regards Oliver ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 13:08 ` any chance of 2.6.0-test*? Dave Jones 2003-01-13 13:40 ` Andrew Walrond 2003-01-13 13:49 ` Oliver Neukum @ 2003-01-14 6:52 ` Bruce Harada 2003-01-14 7:12 ` Brian Tinsley 2 siblings, 1 reply; 173+ messages in thread From: Bruce Harada @ 2003-01-14 6:52 UTC (permalink / raw) To: Dave Jones; +Cc: linux-kernel On Mon, 13 Jan 2003 13:08:42 +0000 Dave Jones <davej@codemonkey.org.uk> wrote: > On Sun, Jan 12, 2003 at 02:34:54PM -0500, Rob Wilkens wrote: > > Wow, one week later, and this would tie in with the fourth anniversary > of someone else[2] making an ass of himself on this issue[1] > > Dave > > [1] http://www.uwsg.iu.edu/hypermail/linux/kernel/9901.2/0939.html > [2] Complete with quaint 'cool' l33t handle. How 90s! *bows head in shame* So does that mean that we can look forward to Rob being a very productive leading Linux developer in four years time? Naaaah.... ;) ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-14 6:52 ` Bruce Harada @ 2003-01-14 7:12 ` Brian Tinsley 0 siblings, 0 replies; 173+ messages in thread From: Brian Tinsley @ 2003-01-14 7:12 UTC (permalink / raw) To: linux-kernel What's happened to Rob??? He's been unusually quiet today! Too many tranquilizers? He must have passed out face down on his keyboard and the drool shorted it out ;) Bruce Harada wrote: >On Mon, 13 Jan 2003 13:08:42 +0000 >Dave Jones <davej@codemonkey.org.uk> wrote: > > > >>On Sun, Jan 12, 2003 at 02:34:54PM -0500, Rob Wilkens wrote: >> >>Wow, one week later, and this would tie in with the fourth anniversary >>of someone else[2] making an ass of himself on this issue[1] >> >> Dave >> >>[1] http://www.uwsg.iu.edu/hypermail/linux/kernel/9901.2/0939.html >>[2] Complete with quaint 'cool' l33t handle. How 90s! *bows head in shame* >> >> > >So does that mean that we can look forward to Rob being a very productive >leading Linux developer in four years time? > >Naaaah.... ;) > > >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ > > -- Brian Tinsley Chief Systems Engineer Emageon ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 19:34 ` Rob Wilkens ` (6 preceding siblings ...) 2003-01-13 13:08 ` any chance of 2.6.0-test*? Dave Jones @ 2003-01-13 15:23 ` Richard B. Johnson 7 siblings, 0 replies; 173+ messages in thread From: Richard B. Johnson @ 2003-01-13 15:23 UTC (permalink / raw) To: Rob Wilkens Cc: Linus Torvalds, Christoph Hellwig, Greg KH, Alan Cox, William Lee Irwin III, Linux Kernel Mailing List On Sun, 12 Jan 2003, Rob Wilkens wrote: > Linus, > > I'm REALLY opposed to the use of the word "goto" in any code where it's > not needed. OF course, I'm a linux kernel newbie, so I'm in no position > to comment > I'm sure Linus can hold his own on this one, but this has become a FAQ or FSB (Frequently stated bitch). Programming 101: All known microprocessors execute instructions called "op-codes". The logic of program-flow is implemented by testing condition "flags" and jumping somewhere else, based upon the condition. These jumps are "GOTOs". To implement logic, you have three, and only three choices. You can jump to some code that's earlier in the instruction stream, you can jump to some code that's later in the instruction-stream, or you can just keep executing the current instruction stream. Assemblers generate op-codes that programmers program. They are not allowed to change anything a programmer inputs. For all practical purposes, they simply change programmer- defined names to processor-specific op-codes. Compilers have more latitude. Compilers, including 'C' compilers attempt to convert logic that a programmer defines to op-codes. Since a compiler needs to generate code that will give the correct logic, regardless of the previous logic or the following logic, it is constrained in its code generation capabilities in a manner that an assembly-language programmer would not necessarily be. However, an astute programmer can, using the tools provided by the compiler, including 'goto', cause code-generation in which the usual case allows the processor to continue executing the current execution-stream without jumping. When the processor is forced to jump on a condition, this usually costs CPU cycles. An astute kernel programmer may spend hours mucking with a single piece of code trying to make it execute as fast as possible. When a new-be comes along and complains about the methods used, he is going to get his feet wet real quickly! Here is an example of how some junior instructors in college teach... if(...){ { if(...){ { if(...){ { They just don't get it. When you get to something that's not true you can't readily "get out". Further, the normal program- flow ends up with all those "ifs". The above code should be: if(!...) goto get_out; if(!...) goto get_out; if(!...) goto get_out; {do something()...} get_out: Cheers, Dick Johnson Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips). Why is the government concerned about the lunatic fringe? Think about it. ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 19:15 ` Linus Torvalds 2003-01-12 19:34 ` Rob Wilkens @ 2003-01-13 6:23 ` Greg KH 2003-01-13 16:35 ` Linus Torvalds 1 sibling, 1 reply; 173+ messages in thread From: Greg KH @ 2003-01-13 6:23 UTC (permalink / raw) To: Linus Torvalds Cc: Christoph Hellwig, Alan Cox, William Lee Irwin III, Linux Kernel Mailing List On Sun, Jan 12, 2003 at 11:15:52AM -0800, Linus Torvalds wrote: > > Anybody willing to test it and see if the above works? Hm, I just did, and it seems to work for me. I ran a bunch of different usb-serial drivers through some tests, but these worked for me without this patch. I don't know what stress tests Alan was running to show up a problem. Anyway, here's a patch with your new lock, if you want to apply it. thanks, greg k-h diff -Nru a/drivers/char/tty_io.c b/drivers/char/tty_io.c --- a/drivers/char/tty_io.c Sun Jan 12 22:27:42 2003 +++ b/drivers/char/tty_io.c Sun Jan 12 22:27:42 2003 @@ -159,6 +159,58 @@ extern void tx3912_rs_init(void); extern void hvc_console_init(void); + +/* +* This isn't even _trying_ to be fast! +*/ +struct recursive_spinlock { + spinlock_t lock; + int lock_count; + struct task_struct *lock_owner; +}; + +static struct recursive_spinlock tty_lock = { + .lock = SPIN_LOCK_UNLOCKED, + .lock_count = 0, + .lock_owner = NULL +}; + +unsigned long tty_spin_lock(void) +{ + unsigned long flags; + struct task_struct *tsk; + + local_irq_save(flags); + preempt_disable(); + tsk = current; + if (spin_trylock(&tty_lock.lock)) + goto got_lock; + if (tsk == tty_lock.lock_owner) { + WARN_ON(!tty_lock.lock_count); + tty_lock.lock_count++; + return flags; + } + spin_lock(&tty_lock.lock); +got_lock: + WARN_ON(tty_lock.lock_owner); + WARN_ON(tty_lock.lock_count); + tty_lock.lock_owner = tsk; + tty_lock.lock_count = 1; + return flags; +} + +void tty_spin_unlock(unsigned long flags) +{ + WARN_ON(tty_lock.lock_owner != current); + WARN_ON(!tty_lock.lock_count); + if (!--tty_lock.lock_count) { + tty_lock.lock_owner = NULL; + spin_unlock(&tty_lock.lock); + } + preempt_enable(); + local_irq_restore(flags); +} + static struct tty_struct *alloc_tty_struct(void) { struct tty_struct *tty; @@ -460,7 +512,7 @@ { unsigned long flags; - local_irq_save(flags); // FIXME: is this safe? + flags = tty_spin_lock(); if (tty->ldisc.flush_buffer) tty->ldisc.flush_buffer(tty); if (tty->driver.flush_buffer) @@ -468,7 +520,7 @@ if ((test_bit(TTY_DO_WRITE_WAKEUP, &tty->flags)) && tty->ldisc.write_wakeup) (tty->ldisc.write_wakeup)(tty); - local_irq_restore(flags); // FIXME: is this safe? + tty_spin_unlock(flags); } wake_up_interruptible(&tty->write_wait); @@ -1926,7 +1978,7 @@ fp = tty->flip.flag_buf + TTY_FLIPBUF_SIZE; tty->flip.buf_num = 0; - local_irq_save(flags); // FIXME: is this safe? + flags = tty_spin_lock(); tty->flip.char_buf_ptr = tty->flip.char_buf; tty->flip.flag_buf_ptr = tty->flip.flag_buf; } else { @@ -1934,13 +1986,13 @@ fp = tty->flip.flag_buf; tty->flip.buf_num = 1; - local_irq_save(flags); // FIXME: is this safe? + flags = tty_spin_lock(); tty->flip.char_buf_ptr = tty->flip.char_buf + TTY_FLIPBUF_SIZE; tty->flip.flag_buf_ptr = tty->flip.flag_buf + TTY_FLIPBUF_SIZE; } count = tty->flip.count; tty->flip.count = 0; - local_irq_restore(flags); // FIXME: is this safe? + tty_spin_unlock(flags); tty->ldisc.receive_buf(tty, cp, fp, count); } ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 6:23 ` Greg KH @ 2003-01-13 16:35 ` Linus Torvalds 2003-01-13 18:33 ` Alan Cox 0 siblings, 1 reply; 173+ messages in thread From: Linus Torvalds @ 2003-01-13 16:35 UTC (permalink / raw) To: Greg KH Cc: Christoph Hellwig, Alan Cox, William Lee Irwin III, Linux Kernel Mailing List On Sun, 12 Jan 2003, Greg KH wrote: > > Anyway, here's a patch with your new lock, if you want to apply it. I'd like to have some verification (or some test-suite) to see whether it makes any difference at all before applying it. Alan, what's your load? Linus ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 16:35 ` Linus Torvalds @ 2003-01-13 18:33 ` Alan Cox 2003-01-13 18:01 ` Linus Torvalds 2003-01-13 19:17 ` Andrew McGregor 0 siblings, 2 replies; 173+ messages in thread From: Alan Cox @ 2003-01-13 18:33 UTC (permalink / raw) To: Linus Torvalds Cc: Greg KH, Christoph Hellwig, William Lee Irwin III, Linux Kernel Mailing List On Mon, 2003-01-13 at 16:35, Linus Torvalds wrote: > On Sun, 12 Jan 2003, Greg KH wrote: > > > > Anyway, here's a patch with your new lock, if you want to apply it. > > I'd like to have some verification (or some test-suite) to see whether it > makes any difference at all before applying it. > > Alan, what's your load? Lots of serial activity (standard PC serial ports) with carrier drops present and random oopses appear. I've seen ppp oopses too but don't know if they are related. I tried duplicating it with pty/tty traffic on a dual PPro200 and suprisingly that did the same. Ages ago I chased serial bugs down by doing data transfers between two PC's while one of them was strobing the carrier up and down on the test PC with varying frequencies I've not had time to try that paticular abuse again alas. Alan ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 18:33 ` Alan Cox @ 2003-01-13 18:01 ` Linus Torvalds 2003-01-13 19:17 ` Andrew McGregor 1 sibling, 0 replies; 173+ messages in thread From: Linus Torvalds @ 2003-01-13 18:01 UTC (permalink / raw) To: Alan Cox Cc: Greg KH, Christoph Hellwig, William Lee Irwin III, Linux Kernel Mailing List On 13 Jan 2003, Alan Cox wrote: > > Lots of serial activity (standard PC serial ports) with carrier drops > present and random oopses appear. Well, that would kind of match the locking place - the hangup might well race with IO activity on another CPU. That's exactly the sequence that was protected by the global irq lock. > I tried duplicating it with pty/tty traffic on a dual PPro200 and > suprisingly that did the same. Just regular IO on its own shouldn't trigger this, I _think_ (no hangup event). Although I can actually imagine the "flush_to_ldisc()" racing with itself on a pty (with the master flushing the slave as the slave flushes itself), so maybe it could actually happen.. But if your pty tests closed the master and forced hangups that way, the race would be more likely. Do you still have the pty stress-test program? > Ages ago I chased serial bugs down by doing data transfers between two > PC's while one of them was strobing the carrier up and down on the test > PC with varying frequencies Yeah, that hangup path is one of the nastier tty events, and it's also oen that doesn't get much testing in many "normal" loads. Linus ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 18:33 ` Alan Cox 2003-01-13 18:01 ` Linus Torvalds @ 2003-01-13 19:17 ` Andrew McGregor 1 sibling, 0 replies; 173+ messages in thread From: Andrew McGregor @ 2003-01-13 19:17 UTC (permalink / raw) To: Alan Cox, Linus Torvalds Cc: Greg KH, Christoph Hellwig, William Lee Irwin III, Linux Kernel Mailing List I believe I may have seen it on 2.5.53 just surfing on an Alcatel Speedtouch DSL modem (using PPPoATM) while compiling in a background gnome-terminal (and probably running a few other things, maybe including top, in terminals). I'll try to confirm that. Andrew --On Monday, January 13, 2003 18:33:31 +0000 Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: > On Mon, 2003-01-13 at 16:35, Linus Torvalds wrote: >> On Sun, 12 Jan 2003, Greg KH wrote: >> > >> > Anyway, here's a patch with your new lock, if you want to apply it. >> >> I'd like to have some verification (or some test-suite) to see whether >> it makes any difference at all before applying it. >> >> Alan, what's your load? > > Lots of serial activity (standard PC serial ports) with carrier drops > present and random oopses appear. I've seen ppp oopses too but don't know > if they are related. I tried duplicating it with pty/tty traffic on a dual > PPro200 and suprisingly that did the same. > > Ages ago I chased serial bugs down by doing data transfers between two > PC's while one of them was strobing the carrier up and down on the test > PC with varying frequencies > > I've not had time to try that paticular abuse again alas. > > Alan > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-12 17:05 ` Linus Torvalds 2003-01-12 17:17 ` Christoph Hellwig @ 2003-01-12 17:37 ` Russell King 1 sibling, 0 replies; 173+ messages in thread From: Russell King @ 2003-01-12 17:37 UTC (permalink / raw) To: Linus Torvalds Cc: Greg KH, Alan Cox, William Lee Irwin III, Linux Kernel Mailing List On Sun, Jan 12, 2003 at 09:05:16AM -0800, Linus Torvalds wrote: > The only place that looked like it _really_ didn't get the kernel lock was > apparently tty_open(), which is admittedly a fairly important part of it ;) chrdev_open() kindly takes the BKL for tty_open() so there isn't an issue here. There were, however, parts of the code which were using the global-cli(), and these merely got converted to local_irq_save() without (iirc) too much auditing. They're all marked with FIXME in my current sources. One thing that regularly bugs me about our current tty implementation, however, is the handling of SIGWINCH. This is sent to the process group rather than the session. Take the following example: - you're running an xterm, with a shell inside. - you're running 3 ssh connections, 2 suspended, one running. - you resize the xterm The WINCH signal will be sent to just the one foreground ssh connection. - you suspend the current ssh. The shell believes that the terminal is the _old_ size. - you resume one of the old ssh sessions. Likewise, ssh doesn't believe the terminal has changed size. My current "workaround" is to re-tweak the xterm size each time I resume or suspend an old process. POSIX (at least signal and general terminal interface sections) seems to be rather quiet on the behaviour of WINCH. Are there any reasons why we shouldn't send WINCH to the whole session rather than just the pgrp associated with the tty? -- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-10 16:10 any chance of 2.6.0-test*? William Lee Irwin III 2003-01-10 16:28 ` Dave Jones 2003-01-10 17:19 ` Alan Cox @ 2003-01-13 1:08 ` Michael Kingsbury 2003-01-13 1:52 ` William Lee Irwin III 2 siblings, 1 reply; 173+ messages in thread From: Michael Kingsbury @ 2003-01-13 1:08 UTC (permalink / raw) To: William Lee Irwin III; +Cc: linux-kernel > Say, I've been having _smashing_ success with 2.5.x on the desktop and > on big fat highmem umpteen-way SMP (NUMA even!) boxen, and I was > wondering if you were considering 2.6.0-test* anytime soon. > > I'd love to get this stuff out for users to hammer on ASAP, and things > are looking really good AFAICT. > > Any specific concerns/issues/wishlist items you want taken care of > before doing it or is it a "generalized comfort level" kind of thing? > Let me know, I'd be much obliged for specific directions to move in. As long as I can't unzip the latest, do a quick 'make xconfig' w/o changing the defaults, followed by 'make bzImage', and actually get the sucker to compile, I'd say go for it. But there's still too much breakage. And until that breakage is fixed, you won't get the next wave of people (users) who are curious to poke around with it. (some of us don't care to take half a day just to figure out what to do to make something compile because there's problems in the source.) (Yes, I realize I have to customize the kernel some. But at the very least the defaults shouldn't cause it to fall flat on its face.) -mike ^ permalink raw reply [flat|nested] 173+ messages in thread
* Re: any chance of 2.6.0-test*? 2003-01-13 1:08 ` Michael Kingsbury @ 2003-01-13 1:52 ` William Lee Irwin III 0 siblings, 0 replies; 173+ messages in thread From: William Lee Irwin III @ 2003-01-13 1:52 UTC (permalink / raw) To: Michael Kingsbury; +Cc: linux-kernel At some point in the past, I wrote: >> Any specific concerns/issues/wishlist items you want taken care of >> before doing it or is it a "generalized comfort level" kind of thing? >> Let me know, I'd be much obliged for specific directions to move in. On Sun, Jan 12, 2003 at 08:08:42PM -0500, Michael Kingsbury wrote: > As long as I can't unzip the latest, do a quick > 'make xconfig' w/o changing the defaults, > followed by > 'make bzImage', > and actually get the sucker to compile, I'd say go for it. But there's > still too much breakage. And until that breakage is fixed, you won't get > the next wave of people (users) who are curious to poke around with it. > (some of us don't care to take half a day just to figure out what to do to make something compile because > there's problems in the source.) > (Yes, I realize I have to customize the kernel some. But at the very > least the defaults shouldn't cause it to fall flat on its face.) Hmm, I never do this, I've been recycling my own .configs for some time. Sounds like a valid concern, I'll give it a shot. Bill ^ permalink raw reply [flat|nested] 173+ messages in thread
end of thread, other threads:[~2003-01-18 12:58 UTC | newest] Thread overview: 173+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-01-10 16:10 any chance of 2.6.0-test*? William Lee Irwin III 2003-01-10 16:28 ` Dave Jones 2003-01-10 16:41 ` Zwane Mwaikambo 2003-01-10 17:08 ` Dave Jones 2003-01-10 17:19 ` Alan Cox 2003-01-10 16:40 ` Jeff Garzik 2003-01-10 17:06 ` Dave Jones 2003-01-10 17:25 ` Jeff Garzik 2003-01-10 17:29 ` Linus Torvalds 2003-01-10 18:47 ` J.A. Magallon 2003-01-10 19:37 ` Matthew D. Pitts 2003-01-10 19:51 ` Jeff Garzik 2003-01-14 1:39 ` James H. Cloos Jr. 2003-01-15 21:46 ` [PATCH][RESEND w/ reasonable Subject] alsa before oss in Kconfig James H. Cloos Jr. 2003-01-10 18:16 ` any chance of 2.6.0-test*? Alan Cox 2003-01-10 17:37 ` Jochen Friedrich 2003-01-10 17:38 ` Linus Torvalds 2003-01-12 9:27 ` Greg KH 2003-01-12 16:55 ` Alan Cox 2003-01-12 17:05 ` Linus Torvalds 2003-01-12 17:17 ` Christoph Hellwig 2003-01-12 19:15 ` Linus Torvalds 2003-01-12 19:34 ` Rob Wilkens 2003-01-12 19:37 ` Rob Wilkens 2003-01-12 19:53 ` Tomas Szepe 2003-01-12 20:03 ` Rob Wilkens 2003-01-13 15:43 ` Terje Eggestad 2003-01-13 15:49 ` Jens Axboe 2003-01-13 16:25 ` Terje Eggestad 2003-01-13 16:26 ` Jens Axboe 2003-01-13 16:41 ` Terje Eggestad 2003-01-13 16:43 ` Jens Axboe 2003-01-13 17:00 ` Zwane Mwaikambo 2003-01-13 18:48 ` Jens Axboe 2003-01-13 22:14 ` Keith Owens 2003-01-13 22:42 ` John Levon 2003-01-13 22:49 ` Zwane Mwaikambo 2003-01-13 23:32 ` Valdis.Kletnieks 2003-01-13 23:43 ` Zwane Mwaikambo 2003-01-12 20:44 ` Alan Cox 2003-01-12 20:45 ` William Lee Irwin III 2003-01-13 13:14 ` Bernd Schmidt 2003-01-12 21:22 ` David Woodhouse 2003-01-18 13:04 ` Folkert van Heusden 2003-01-12 19:38 ` Linus Torvalds 2003-01-12 19:59 ` Rob Wilkens 2003-01-12 20:18 ` Valdis.Kletnieks 2003-01-12 20:23 ` yodaiken 2003-01-12 20:26 ` Tomas Szepe 2003-01-12 20:32 ` Sean Neakums 2003-01-12 20:51 ` Valdis.Kletnieks 2003-01-13 0:54 ` Randy Dunlap 2003-01-12 20:46 ` Kevin Puetz 2003-01-13 0:48 ` Randy Dunlap 2003-01-18 13:07 ` Folkert van Heusden 2003-01-12 20:20 ` David Ford 2003-01-12 20:22 ` Linus Torvalds 2003-01-12 20:33 ` Robert Love 2003-01-12 20:33 ` Linus Torvalds 2003-01-13 10:54 ` Horst von Brand 2003-01-13 11:09 ` Eric W. Biederman 2003-01-13 14:34 ` Terje Eggestad 2003-01-13 23:23 ` Bob Taylor 2003-01-12 20:48 ` Rob Wilkens 2003-01-12 20:59 ` Dimitrie O. Paun 2003-01-12 22:48 ` any chance of 2.6.0-test*? -> goto example Willy Tarreau 2003-01-13 0:53 ` Rob Wilkens 2003-01-13 1:31 ` Willy Tarreau 2003-01-13 16:10 ` Alexander Kellett 2003-01-14 10:36 ` Helge Hafting 2003-01-12 23:11 ` Coding style - (Was Re: any chance of 2.6.0-test*?) John Bradford 2003-01-13 11:07 ` any chance of 2.6.0-test*? Helge Hafting 2003-01-13 3:30 ` yodaiken 2003-01-12 21:29 ` Rik van Riel 2003-01-13 0:03 ` Scott Robert Ladd 2003-01-13 0:38 ` Rob Wilkens 2003-01-13 3:06 ` [OT] " J Sloan 2003-01-13 16:51 ` Emiliano Gabrielli 2003-01-13 0:38 ` Randy Dunlap 2003-01-12 19:41 ` Christoph Hellwig 2003-01-12 19:41 ` Rob Wilkens 2003-01-12 19:58 ` David Ford 2003-01-12 20:07 ` Rob Wilkens 2003-01-12 20:31 ` Oliver Neukum 2003-01-12 20:34 ` David Ford 2003-01-12 20:31 ` Robert Love 2003-01-12 21:02 ` Rob Wilkens 2003-01-12 21:15 ` Matti Aarnio 2003-01-12 21:27 ` Rob Wilkens 2003-01-12 21:40 ` Rik van Riel 2003-01-12 21:44 ` Rob Wilkens 2003-01-12 21:49 ` Aaron Lehmann 2003-01-12 22:07 ` Rob Wilkens 2003-01-12 22:18 ` Aaron Lehmann 2003-01-12 22:34 ` Rob Wilkens 2003-01-12 22:52 ` Aaron Lehmann 2003-01-12 23:11 ` Rob Wilkens 2003-01-12 23:31 ` Oliver Neukum 2003-01-12 23:39 ` Emiliano Gabrielli 2003-01-12 23:46 ` Rob Wilkens 2003-01-12 23:57 ` Emiliano Gabrielli 2003-01-13 0:08 ` Rob Wilkens 2003-01-13 16:02 ` Terje Eggestad 2003-01-12 22:53 ` Sean Neakums 2003-01-12 23:06 ` Oliver Neukum 2003-01-12 23:48 ` Rik van Riel 2003-01-12 21:58 ` Emiliano Gabrielli 2003-01-12 22:12 ` Rob Wilkens 2003-01-12 22:29 ` Olivier Galibert 2003-01-12 23:21 ` Alan Cox 2003-01-12 22:12 ` Oliver Neukum 2003-01-12 22:18 ` Aaron Lehmann 2003-01-12 22:35 ` Rob Wilkens 2003-01-13 8:15 ` Jens Axboe 2003-01-12 21:49 ` David Ford 2003-01-13 19:22 ` [OffTopic] [apology] " Rob Wilkens 2003-01-12 21:59 ` Adam Kropelin 2003-01-12 22:21 ` Rob Wilkens 2003-01-12 22:33 ` Tomas Szepe 2003-01-12 22:36 ` Emiliano Gabrielli 2003-01-12 22:38 ` Oliver Neukum 2003-01-12 22:42 ` romieu 2003-01-13 1:06 ` Randy Dunlap 2003-01-13 1:21 ` Rob Wilkens 2003-01-13 1:51 ` Nuno Monteiro 2003-01-13 2:19 ` Rob Wilkens 2003-01-13 2:51 ` Marcelo Pacheco 2003-01-13 3:37 ` Rob Wilkens 2003-01-13 4:53 ` Billy Rose 2003-01-13 3:06 ` Jochen Striepe 2003-01-13 3:40 ` Rob Wilkens 2003-01-13 9:45 ` Matti Aarnio 2003-01-13 3:48 ` Ryan Anderson 2003-01-13 4:37 ` Billy Rose 2003-01-12 22:06 ` Oliver Neukum 2003-01-12 22:22 ` Rob Wilkens 2003-01-12 22:43 ` Oliver Neukum 2003-01-12 22:51 ` Rob Wilkens 2003-01-12 23:00 ` Robert Love 2003-01-12 23:16 ` Rob Wilkens 2003-01-12 23:16 ` Nicolas Pitre 2003-01-12 23:05 ` Emiliano Gabrielli 2003-01-12 23:23 ` Oliver Neukum 2003-01-12 23:45 ` Emiliano Gabrielli 2003-01-12 23:45 ` Emiliano Gabrielli 2003-01-13 20:01 ` Horst von Brand 2003-01-12 23:16 ` Oliver Neukum 2003-01-13 2:00 ` Ryan Anderson 2003-01-13 3:09 ` Rob Wilkens 2003-01-14 2:13 ` Rik van Riel 2003-01-12 22:58 ` Robert Love 2003-01-12 22:28 ` Matti Aarnio 2003-01-13 1:26 ` David Lang 2003-01-13 2:00 ` William Lee Irwin III 2003-01-13 11:08 ` How to avoid the woord 'goto' (was Re: any chance of 2.6.0-test*?) Bernd Petrovitsch 2003-01-13 14:56 ` Rob Wilkens 2003-01-13 22:02 ` any chance of 2.6.0-test*? Val Henson 2003-01-13 10:32 ` gotos in kernel [Was: Re: any chance of 2.6.0-test*?] Horst von Brand 2003-01-13 14:53 ` Rob Wilkens 2003-01-13 13:08 ` any chance of 2.6.0-test*? Dave Jones 2003-01-13 13:40 ` Andrew Walrond 2003-01-13 13:49 ` Oliver Neukum 2003-01-14 6:52 ` Bruce Harada 2003-01-14 7:12 ` Brian Tinsley 2003-01-13 15:23 ` Richard B. Johnson 2003-01-13 6:23 ` Greg KH 2003-01-13 16:35 ` Linus Torvalds 2003-01-13 18:33 ` Alan Cox 2003-01-13 18:01 ` Linus Torvalds 2003-01-13 19:17 ` Andrew McGregor 2003-01-12 17:37 ` Russell King 2003-01-13 1:08 ` Michael Kingsbury 2003-01-13 1:52 ` William Lee Irwin III
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).