On Monday 29 February 2016 06:47:26 EXT Bill Fischofer wrote:
> 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.
>
Well, and invalidation function like this is fairly more quick than
calling destroy, allowing you copy the reference to some other place for
the house keeping, and marking this as invalid in no time. Later on is up to
us when we clean that up(when we are idle or we have no option).
Marking it as invalid, allow us to let the interface be dirty until
either we want to check for broken queues or we want to use it. At the
former case, if we want to use it, we can either skip the broken queue or
recreate it on the run.
In the end I just feel like it can be worthy, but hei, you have
the last word on that.
Thanks for the previous elaboration!
Best regards.
José.
_______________________________________________
lng-odp mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp
