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

Paolo Bonzini
2011-05-25T10:01:24Z

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