* Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > On 05/24/2011 10:50 AM, Ingo Molnar wrote: > >Yeah, that would certainly work for simple things but there's several reasons > >why explicit control over initcalls is preferred in a tool like tools/kvm/ over > >__attribute__((constructor)): > > Some advantages you mention are real indeed, but they are general; > there's no reason why they apply only to tools/kvm. You can achieve > the same by doing only minimal work (registering your > subsystems/devices/whatever in a linked list) in the constructors. > Then you iterate on the list and call function pointers. Well, the plain fact that __attribute__((constructor)) gets called on binary and shared library startup before main() is called is a show-stopper for us as i described it in my previous mail, so why are we even arguing about it? ((constructor)) has showstopper properties: - We don't have access to the program arguments - stdio is probably not set up yet (this is undefined AFAICS) - Also, over the years i have grown to be suspicious of GCC defined extensions. More often than not the GCC project is fixing regressions not by fixing the compiler but by changing the documentation ;-) We got bitten by regressions in asm() behavior in the kernel rather often. In that sense ((section)) is way more robust: there's not really that many ways to screw that up. Fiddling with the ((constructor)) environment on the other hand ... Note that in terms of explicit iterations we do that with __attribute__((section)) as well: except that *we* define where and how the functions get called. > I know portability is not relevant to tools/kvm/, but using unportable tricks > for the sake of using them is a direct way to NIH. But oh well all of > tools/kvm/ is NIH after all. :) __attribute__((constructor)) is not particularly portable to begin with: does the MSVC compiler support it for example? So __attribute__ ((section)), which is used by the initcall() machinery is similarly portable: GCC and LLVM/Clang support it. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
