lkml.org 
[lkml]   [2003]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: any chance of 2.6.0-test*?
From

<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"


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:32    [W:0.246 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site