On Nov 12, 1:46am, Masao Uebayashi wrote:
} On Wed, Nov 12, 2014 at 1:15 AM, Kamil Rytarowski <n...@gmx.com> wrote:
} > From David Holland
} >> Please don't do that. Nothing good can come of it - you are asking for
} >> a thousand weird problems where undisclosed ordering dependencies
} >> silently manifest as strange bugs.
}
} Everyone is aware of that. Code conversion must be done extremely
} carefully. Order must be preserved.
}
} >> Furthermore, the compiler can and probably will assume that
} >> constructor functions get called before all non-constructor code, and
} >> owing to unavoidable issues in early initialization this will not be
} >> the case in some contexts. (I first hit this problem back in about
} >> 1995ish when some more gung-ho colleagues were trying to use C++
} >> global constructors in a C++ kernel, and we eventually had to declare
} >> a moratorium on all global constructors.)
}
} Thanks, but irrelevant for kernel...
}
} >> init_main.c could use some tidying, but there's nothing fundamentally
} >> wrong with it that will be improved by adding a lot of implicit magic
} >> that doesn't do what the average passerby expects.
}
} Function pointers are not magic.
}
} (snip)
} > And last but not least... what's wrong with init_main.c? It must be clear
for a developer adding a new platform or debugging hardware bring-up. It gives
me big picture on that what's going on step-by-step, even when I was lurking
into assembly of our kernel... call it, call that, call this.. making it all
clear.
}
} Those functions are hardcoded and ordered even without dependencies
} among them, that's a big problem.
Without dependencies?!? The ordering gives the dependencies.
} The biggest problem of constructors (and indirect function call in
} general), I am aware of, is, static code analysis (code reading, tag
} jump, ...) becomes difficult (or impossible).
Considering that we're talking about the kernel, this is an
extremely huge flaw! As in, DON'T do it!
}-- End of excerpt from Masao Uebayashi
