Re: kernel constructor

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

On Wed, Nov 12, 2014 at 1:15 AM, Kamil Rytarowski <n54%gmx.com@localhost> 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.

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).