From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [PATCH 5/5 V2] kvm tools: Initialize and use VESA and VNC Date: Wed, 25 May 2011 12:01:08 +0200 Message-ID: <4DDCD364.9090903@redhat.com> 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> <20110525093611.GD28500@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sasha Levin , penberg@kernel.org, john@jfloren.net, kvm@vger.kernel.org, asias.hejun@gmail.com, gorcunov@gmail.com, prasadjoshi124@gmail.com To: Ingo Molnar Return-path: Received: from mx1.redhat.com ([209.132.183.28]:20441 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753051Ab1EYKBY (ORCPT ); Wed, 25 May 2011 06:01:24 -0400 In-Reply-To: <20110525093611.GD28500@elte.hu> Sender: kvm-owner@vger.kernel.org List-ID: On 05/25/2011 11:36 AM, Ingo Molnar wrote: > So can other portability problems be solved, such as linker scripts > can be written for non-ELF targets (should that ever become > necessary) I know that's not going to be the case, and I mentioned that in my first message---portability is not relevant to tools/kvm/ just like it is not relevant say to systemd. > 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"). QEMU _does_ have this problem BTW, we have our own event loop and AIO, our own JSON parser, our own thread abstractions, and so on... > We want to use ELF sections in the future *anyway* to make > tools/kvm/ scale even better, for example to use alternative > instruction fixups (for which no GCC extension exists) so a linker > script will be there anyway. Since you're not writing the hypervisor, but only the device model, I doubt that this is needed (and you'd likely run into troubles with SELinux). QEMU scales to dozens of VCPUs with a big lock around all userspace device model code. But it's premature to say that, and I'd be happy if I were proven wrong. > Fact is that neither ((section)) *NOR* ((constructor)) is portable: > *both* are GCC extensions - while you falsely claimed that > ((constructor)) was somehow portable and that ((section)) was an > 'unportable trick'. Fair enough. I agree that ((constructor)) has limited scope and is compiler-unportable. ((section)) is more powerful and has the cost of using also target-unportable linker scripts, and requiring changes to the build system. Both have the same problem with static libraries (please reread my message). >>>>>> 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! 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). Paolo