Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 12 Jan 2003 17:14:08 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 12 Jan 2003 17:14:08 -0500 Received: from mta2.srv.hcvlny.cv.net ([167.206.5.5]:27609 "EHLO mta2.srv.hcvlny.cv.net") by vger.kernel.org with ESMTP id ; Sun, 12 Jan 2003 17:14:07 -0500 Date: Sun, 12 Jan 2003 17:21:00 -0500 From: Rob Wilkens Subject: Re: any chance of 2.6.0-test*? In-reply-to: <20030112215949.GA2392@www.kroptech.com> To: Adam Kropelin Cc: Matti Aarnio , Linux Kernel Mailing List Reply-to: robw@optonline.net Message-id: <1042410059.1208.150.camel@RobsPC.RobertWilkens.com> Organization: Robert Wilkens MIME-version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Content-type: text/plain Content-transfer-encoding: 7BIT References: <1042400094.1208.26.camel@RobsPC.RobertWilkens.com> <20030112211530.GP27709@mea-ext.zmailer.org> <1042406849.3162.121.camel@RobsPC.RobertWilkens.com> <20030112215949.GA2392@www.kroptech.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2416 Lines: 50 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 - 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/