>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 > dholl...@netbsd.org >
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.
