A bit of history may be helpful here. Originally we used typedefs in ODP fairly casually, as in:
typedef uint32_t odp_queue_t; typedef uint32_t odp_pool_t; etc. Unfortunately typedefs in C are not strongly typed, meaning that you could pass a queue handle to an API that was expecting a pool handle and the C compiler would happily accept that. So we came up with the conventions used in linux-generic to make ODP strongly typed by taking advantage of the fact that C does regard things it sees as unions or structs to be different types even if they have the same contents. On Mon, Feb 29, 2016 at 6:09 AM, José Pekkarinen <[email protected]> wrote: > On Monday 29 February 2016 05:52:23 EXT Bill Fischofer wrote: > > > I thought you were using ODP in an application. This sounds like you're > > > creating your own ODP implementation, in which case the result is that > you > > > have a properly typed definition of ODP_QUEUE_INVALID of type > odp_queue_t. > > > In this case the assignment works so I guess I'm now confused what the > > > issue is. > > > > > > > Hi, > > > > Yes, this is the case, I'm working in supporting a platform in odp, and > the code defines odp_queue_t as an union. In that context, defining > ODP_QUEUE_INVALID as, for instance: > > > > #define ODP_QUEUE_INVALID ~(unsigned)0 > > > > Is not something we can afford, as it should be compared with queue.u64. > Is there any other way to define ODP_QUEUE_INVALID that is not depending in > _odp_cast_scalar()? > _odp_cast_scalar() is just a convenience macro that does a bunch of casting tricks to make a distinguished value type compatible with the designated type. That means that ODP_QUEUE_INVALID winds up having type odp_queue_t, which is what you want, rather than type uint64_t or something else. Since it is just casts it's all done at compile time and involves no runtime overhead. You're free to use it in another ODP implementation or define your own constructs. ODP_QUEUE_INVALID is simply a distinguished value of type odp_queue_t that represents an invalid queue handle. All that means is that odp_queue_create() will never return a valid queue handle with that specific value. Implementations are free to choose whatever value they want since the specific value is opaque and not visible to ODP applications. > > > > An ODP application should never reference the internals of an ODP > > > implementation, but of course an ODP implementation must do so. If your > > > implementation wishes to borrow constructs from linux-generic like > > > _odp_cast_scalar() that's perfectly fine. That's why we provide reference > > > implementations of ODP--to enable other implementations to use the code > as > > > scaffolding for their own implementations. > > > > > > Have I misunderstood what the root issue is here? > > > > > > > I hope not, because otherwise I'm lacking ways to get this explained > anymore. > > > > Coming back to the patch, it's just providing flexibility to let the > platform provide it's own way to define the invalidation. If this is not > something good enough, just feel free not to consider it. > I guess I don't see how the patch accomplishes that. ODP already defines a way to "invalidate" a queue handle by destroying it. In my previous post I mentioned that you can assign ODP_QUEUE_INVALID to a variable of type odp_queue_t as a means of noting that the variable doesn't represent a valid queue, but if you create a queue you're under obligation to destroy it as part of cleanup at some point. When you choose to do that is up to you, but you can't avoid the obligation. > > > Best regards. > > > > José. > > >
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
