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: Wed, 25 May 2011 11:49:50 +0200 Message-ID: <20110525094950.GA22008@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> <4DDB77E5.4080306@redhat.com> <20110524194019.GA27634@elte.hu> <4DDCBC08.3030507@redhat.com> <20110525083200.GF21552@elte.hu> <4DDCC8A0.8050708@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]:35256 "EHLO mx2.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754888Ab1EYJuC (ORCPT ); Wed, 25 May 2011 05:50:02 -0400 Content-Disposition: inline In-Reply-To: <4DDCC8A0.8050708@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: * Paolo Bonzini wrote: > On 05/25/2011 10:32 AM, Ingo Molnar wrote: > > > >* Paolo Bonzini wrote: > > > >>> 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 ... > >> > >> Sorry, this is textbook FUD. > > > > I specifically cited the problem of static libraries. They *do > > not work* with ((constructor)). > > ((constructor)) has easily explained semantics: it's the same > semantics as C++ global constructors. If you don't like those, > that's another story. It is a plain *bug* if device initialization is not being executed if kvm is linked into a static library using the regular way of how libraries are created ... No amount of arguing about 'semantics' will change that simple fact: it breaks code so it's a bug. We don't want to rely on a facility that handles boundary conditions in such a poor way. See my prior point: - 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 ... You are demonstrating this phenomenon rather well. You argue against plain old bugs with 'but these are well-defined semantics'. That's not how we deal with bugs in tools/kvm/ really. And then you argue that the bug can be worked around by writing a linker script: > compilation with static libraries: > $ gcc f.c -o f.o -c > $ gcc f1.c -o f1.o -c > $ ar cr f1.a f1.o > $ ld -r f.ld f.o f1.a -o f2.o > $ gcc f2.o -o a.out > $ ./a.out > 12345678 I will rather use linker scripts and less erratic facilities straight away. Thanks, Ingo