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

-
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.123 / U:20.824 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site