qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 4/7] compiler: add macro for GCC weak symbols


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 4/7] compiler: add macro for GCC weak symbols
Date: Sat, 28 Jul 2012 08:25:47 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)

Anthony Liguori <address@hidden> writes:

> Blue Swirl <address@hidden> writes:
>
>> On Fri, Jul 27, 2012 at 8:51 PM, Anthony Liguori <address@hidden> wrote:
>>> If someone comes along and actively maintains support for another
>>> compiler, we can revisit.  But otherwise, there's no practical reason to
>>> avoid extensions.

Exactly.

>> Because it's more compliant to standards.
>
> That is not a benefit.  There is no practical advantage to sticking to
> only C99.

Agree.  "Compliance to X" is means, not ends.  Specifically, compliance
to C99 is not a benefit by itself.  Portability to desirable targets is
one.

Right now, the code is portable enough for our current needs.  If you
find a target you wish to support where it doesn't work, patches are
welcome.

> If we stuck to C99 only, QEMU would look very different.  We wouldn't
> have type_init() so we wouldn't have the module system we use today.
> It literally took me months to get those patches merged because Paul
> made exactly the same argument you're making now.
>
> And it's really been one of the better cleanups in QEMU that we've ever
> done (using modules to define devices).

Developing is hard enough without tying ourselves into knots to avoid
useful tools just because they haven't been blessed by the right
standards committee.  Some pragmatism is in order.

>> There's also very little benefit from using the nonessential
>> extensions.

Blanket statement, needs evidence.

> Using weak symbols eliminates #ifdefs and makes the code base a lot
> cleaner.  It makes it easier to introduce architecture specific hooks in
> a clean way.
>
> Considering how messy a lot of our target-specific code is, I think
> there could be quite a significant benefit down the road.

I don't have an informed opinion on this particular case.  All I can say
here is patches are evidence.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]