Re: [PATCH 5/5 V2] kvm tools: Initialize and use VESA and VNC

[Ingo Molnar <mingo@elte.hu>]

* Paolo Bonzini <pbonzini@redhat.com> 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