On 7/12/2016 12:42 PM, Andrew Cooper wrote:
On 12/07/16 06:11, Corneliu ZUZU wrote:
Hi Andrew,
On 7/11/2016 6:18 PM, Andrew Cooper wrote:
On 09/07/16 05:12, Corneliu ZUZU wrote:
This wouldn't let me make a param of a function that used
atomic_read() const.
Signed-off-by: Corneliu ZUZU <cz...@bitdefender.com>
This is a good improvement, but you must make an identical adjustment to
the arm code, otherwise you will end up with subtle build failures.
Right, didn't even realize it was X86-specific.
It isn't x86 specific. (Which is what I presume you meant to say.)
Heh, yes, depends how you look at it, I was referring precisely to (the
implementation of) the function I've modified (which was X86-specific,
called from common, which meant there's an ARM one as well).
If you are really feeling up to it, having a common xen/atomic.h with
typedef struct { int counter; } atomic_t;
#define ATOMIC_INIT(i) { (i) }
and some prototypes such as:
static inline int atomic_read(const atomic_t *v);
would be great, but this looks like it has the possibility to turn into
a rats nest. If it does, then just doubling up this code for arm is ok.
~Andrew
Yes, that might be more complicated than we expect and I don't know if
making code such as this common would be a good idea, usually these
functions are always architecture-specific.
I only suggested making the prototype common, not the implementation.
As such, the issue you accidentally introduced would become a hard build
failure on affected architectures, rather than a subtle build failure in
common code at some point in the future.
~Andrew
Oh, I see, good idea, I've just tested it and it works, what did you
have in mind when you said it could cause problems?
Zuzu C.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
