* Paolo Bonzini <pbonz...@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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
