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 12:17:44 +0200 Message-ID: <20110525101744.GA30983@elte.hu> References: <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> <20110525093611.GD28500@elte.hu> <4DDCD364.9090903@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 mx3.mail.elte.hu ([157.181.1.138]:34764 "EHLO mx3.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751609Ab1EYKR5 (ORCPT ); Wed, 25 May 2011 06:17:57 -0400 Content-Disposition: inline In-Reply-To: <4DDCD364.9090903@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: * Paolo Bonzini wrote: > > so what's your point? > > Using this kind of trick makes it harder to share code with other > libraries that may require a higher standard of portability (not > "better" or "worse", just "higher"). [...] That's an complication but should be fixable, should it ever happen. As things stand today we: - Are *already* using an ELF linker script, see tools/kvm/bios/rom.ld.S - Have multiple valid reasons not to use ((constructor)) - Want to use sections to implement other useful features as well If the *only* linker script use would be the init facility then you'd probably have a valid point - although the possible code flow fragility with ((constructor)) is still a problem: we still would want to know when no constructors were executed. Also it's not clear why ((constructor)) was written in the way it was: why apparently no access is given to the array of init functions and why it's not possible to turn the auto-execution off but still have the array generated, for legitimate cases that want to use data driven constructor execution. > >>>>>> 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. :) > > > > Btw., that NIH claim was rather unfair and uncalled for as well. > > Hey hey I put a smiley for a reason! Well after two insults in a single paragraph you need to put in at least two smileys! Or not write the insults in a technical discssion to begin with, especially if you are criticising a patch rather forcefully. It will be easily misunderstood as a real insult, despite the smiley ;-) > Anyway I think we both agree that this debate is pointless. I > learnt something (I wasn't aware of interaction between > ((constructor)) and static libraries), you learnt something (it's > the same with ((section)), and it's intrinsic in how static > libraries work). While i did not know whether static libraries would work with a linker script (never tried it - and your experiment suggests that they wont), the ((section)) approach we could create a clear runtime BUG_ON() assert for a zero-sized array of init function pointers, while ((constructor)) will silently not execute initialization functions. Thanks, Ingo