From mboxrd@z Thu Jan  1 00:00:00 1970
From: pbonzini@redhat.com (Paolo Bonzini)
Date: Mon, 15 Feb 2010 17:36:30 +0100
Subject: [ltt-dev] [PATCH 07/11] add uatomic_gcc.h,
 use it for default definitions
In-Reply-To: <20100215162354.GA21995@Krystal>
References: <1266081392-8732-1-git-send-email-pbonzini@redhat.com>
	<1266081392-8732-8-git-send-email-pbonzini@redhat.com>
	<20100214144525.GH5871@Krystal> <4B79004C.7090407@redhat.com>
	<20100215145520.GC13436@Krystal> <4B796A92.9030308@redhat.com>
	<20100215162354.GA21995@Krystal>
Message-ID: <4B79780E.6060104@redhat.com>

On 02/15/2010 05:23 PM, Mathieu Desnoyers wrote:
> 1) We choose to discard support for old compilers on all architectures.
>    + simple/clean code
>    + easier to maintain
>    + less error-prone, using widely tested gcc builtins.
>    - liburcu become incompatible with lots of systems still being used today.

This is v1 of my patchset, and I understand it's too much.  (To be 
precise v1 was a bit less strict, as x86 and SPARC64 would remain 
compatible with old compilers).

It is too aggressive considering the other possibilities.

> 2) We choose to stick to custom per-architecture macros (only).
>    - more complex code.
>    - more code to maintain.
>    - more testing needed because we are not using gcc builtins.
>    - requires an initial effort to port liburcu to new architectures.
>    + provides support for gcc compilers back to early 3.x versions.
>    + test suites covers all gcc versions (no special-cases for old vs new
>      versions). Ensures that the code does not get bitrotten by not being
>      tested.

This is the status quo, besides the fact that S390 and SPARC64 are 
already using GCC builtins in non-public headers.

> 3) We choose to stick to custom per-arch macros, and use gcc builtins for
>     architectures for new architectures we want to support.
>     Same ? as (2), with this distinction:
>     + diminish initial port effort, because we can provide support for
>       new architectures (except for old compilers) quickly by using builtins.
>
> 4) Detect compiler versions with the precompiler. Use builtins for new
>     compilers, and explicit declarations for old compilers.
>    - more complex code.
>    - more code to maintain.
>    - more testing needed because we are not using gcc builtins.
>    - requires an initial effort to port liburcu to new architectures.
>    - test suites have to test for many compiler versions. Chances are
>      that the "old compiler compatibility" code will get much less
>      tested. This is, IMHO, a recipe for a disaster, as bugs will creap
>      in and testing will be hard.
>    + provides support for gcc compilers back to early 3.x versions.

(5) We choose to discard support for old compilers on all architectures, 
but fallback to non-_LGPL_SOURCE on all compilers
     + simple/clean code
     + easier to maintain
     + less error-prone (even though it's not really possible to use GCC
       builtins everywhere)
    - liburcu becomes less efficient on lots of systems in use today

> The current approach for liburcu is (2), but I think it's good to move
> to (3). However, I really dislike (4) because it makes testing much
> harder, and (1) is, I think, a no-go for a library meant to be usable on
> the large ecosystem of systems we have today (some with old compilers).

Exactly.

(3) is the most balanced and reasonable as things stand now.

(4) is definitely going to bitrot sooner than later (it would cost just 
an #ifdef...#endif around what we have now, but the problem of course is 
what goes inside the #ifdef).

I was thinking of doing (3) with the additional twist that S390 would 
count as a "new architecture".  On it, GCC is providing really 
everything that is needed and furthermore, unlike PPC, your testers 
surely have a new-enough GCC because they're using api_gcc.h.

Switching from (3) to (5) can be done later, after evaluating more 
carefully the pros and cons.  What do you think?

Paolo