Re: [PATCH 5/5 V2] kvm tools: Initialize and use VESA and VNC

[Paolo Bonzini <pbonzini@redhat.com>]

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