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

Ingo Molnar
2011-05-24T19:16:38Z

* 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