From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [PATCH 5/5 V2] kvm tools: Initialize and use VESA and VNC Date: Tue, 24 May 2011 21:16:26 +0200 Message-ID: <20110524191626.GE6561@elte.hu> References: <1306149553-26793-1-git-send-email-levinsasha928@gmail.com> <1306149553-26793-5-git-send-email-levinsasha928@gmail.com> <20110523113824.GE4042@elte.hu> <4DDB6E55.8080408@redhat.com> <20110524085024.GA31453@elte.hu> <4DDB75EC.7000300@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sasha Levin , penberg@kernel.org, john@jfloren.net, kvm@vger.kernel.org, asias.hejun@gmail.com, gorcunov@gmail.com, prasadjoshi124@gmail.com To: Paolo Bonzini Return-path: Received: from mx2.mail.elte.hu ([157.181.151.9]:37708 "EHLO mx2.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754648Ab1EXTQi (ORCPT ); Tue, 24 May 2011 15:16:38 -0400 Content-Disposition: inline In-Reply-To: <4DDB75EC.7000300@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: * Paolo Bonzini 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