<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 Gabriellidip. 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/
This archive was generated by hypermail 2b29 : Wed Jan 15 2003 - 22:00:42 EST