On 22 April 2015 at 13:24, Maxim Uvarov <[email protected]> wrote:
> On 04/22/15 14:20, Maxim Uvarov wrote: > >> On 04/22/15 13:34, Nicolas Morey-Chaisemartin wrote: >> >>> >>> On 04/22/2015 11:39 AM, Maxim Uvarov wrote: >>> >>>> In that case what you need is. >>>> >>>> That is odp API: >>>> ./include/odp/api/atomic.h >>>> >>>> That is platfrom implementation (linux-generic): >>>> ./platform/linux-generic/include/odp/atomic.h >>>> >>>> That is some internal functions which linux-generic platfrom does. >>>> ./platform/linux-generic/include/odp_atomic_internal.h >>>> >>>> So that what you need is move >>>> ./platform/linux-generic/include/odp/atomic.h to >>>> ./platform/your-platfrom/include/odp/atomic.h >>>> and re implement functions there. >>>> >>>> Is that original question? >>>> >>>> Best regards, >>>> Maxim. >>>> >>>> >>>> >>>> >>>> That's what I did. But our implementation is mostly based on the >>> linux-generic now. And as I had to implement almost the same atomic >>> functions twice, I was thinking it would make sense to refactor this code >>> in the linux-generic tree too. >>> >>> Nicolas >>> >>> Ok, got it now. >> >> Ola, I think that it can be reworked and because all odp_timer.c, >> odp_ticketlock.c and odp_rwlock.c use _ODP_MEMMODEL_RLX they can also use >> api function, not _internal.h right? >> > The implementation of synchronization operations (locks, barriers etc) use all kind of memory orderings, especially acquire and release. I don't know and really don't care exactly how the final solution will look like, the person who does the work will have to find something that works. But we should agree on some prerequisites. Should the atomic operations in linux-generic/include/odp_atomic_internal.h become public (that would be the simplest solution me thinks) or stay private? If stay private, is there some way for the public operations in include/odp/api/atomic.h to use the operations in odp_atomic_internal.h which are not considered public? I.e. can you implement a public API using non-public (private) definitions? >> Thanks, >> Maxim. >> > more compex thing is odp_rwlock.c I think as it operates all this flags. > > > >
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
