* Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > So you claim that ((section)) is 'not portable' but concede that > > it does in fact not port to one of the most widely used > > compilers. > > Can you please avoid trimming messages? I said "the differences > between MSVC and GCC can easily be abstracted with a macro". This > is not unlike other differences between the two compilers (e.g. > __forceinline vs. the ((always_inline)) attribute), and it is not > true of linker scripts. So ((constructor)) is unportable but it can be wrapped. So can other portability problems be solved, such as linker scripts can be written for non-ELF targets (should that ever become necessary), so what's your point? 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. ( We might also want to use sections to speed up exception handling in tools/kvm/. ) 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'. Let me quote your initial claim: >>>>> 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. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
