Re: kernel constructor

["Kamil Rytarowski" <n54%gmx.com@localhost>]

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.
> 
> 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.)
> 
> 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.
> 
> -- 
> David A. Holland
> dholland%netbsd.org@localhost
> 

Hello,

Invitation for kernel constructors and destructors (in meaning of GNU extension) looks as not being appropriate to me:
- it's not standardized in C language, so people and tool-chain have right to be not familiar with it or not implement it the same way, neither preserve the same functionality in long term...,
- we can lost control over function calling order,
- if we really want such constructors it's doable with simple callback functions (a module is registering callback to be executed by a master process).

Privately I always considered __attribute__((constructor)) and __attribute__((destructor)) as a sign of bad design, with need to be boosted by extensions. Normally (always?) constructors are called before entering main()... I prefer to get the console/uart ready as soon as possible, not after a set of procedures initialized by a list of modules when we can got frozen without legible output.

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.