On Mon, 4 May 2020 16:39:32 +0200
Jean-Philippe Brucker <jean-phili...@linaro.org> wrote:
> On Thu, Apr 30, 2020 at 01:48:42PM -0700, Jacob Pan wrote:
> > On Thu, 30 Apr 2020 11:39:31 -0700
> > Jacob Pan <jacob.jun....@linux.intel.com> wrote:
> >
> > > > -void ioasid_free(ioasid_t ioasid)
> > > > +bool ioasid_free(ioasid_t ioasid)
> > > > {
> > Sorry I missed this in the last reply.
> >
> > I think free needs to be unconditional since there is not a good
> > way to fail it.
> >
> > Also can we have more symmetric APIs, seems we don't have
> > ioasid_put() in this patchset.
>
> Yes I was thinking of renaming ioasid_free() to ioasid_put() but got
> lazy.
>
> > How about?
> > ioasid_alloc()
> > ioasid_free(); //drop reference, mark inactive, but not reclaimed if
> > refcount is not zero.
> > ioasid_get() // returns err if the ioasid is marked inactive by
> > ioasid_free()
>
> How does the caller know that the ioasid is in active/inactive state,
> and not freed/reallocated?
>
In inactive state, callers of ioasid_find(), ioasid_get() would all
fail. Only ioasid_put can still operate on it.
In freed state (i.e. not allocated), it will be the same as above with
the exception that ioasid_put has no effect.
> > ioasid_put();// drop reference, reclaim if refcount is 0.
>
> I'll add ioasid_put() for now. I'd like to avoid introducing the
> inactive state in this patch,
Sounds good. I just wanted to consult with you about the above APIs. I
will introduce the state when we have a real use.
> so shall I change the calls in the
> Intel driver to ioasid_put(), and not introduce a new ioasid_free()
> for the moment?
>
Sounds good.
> Thanks,
> Jean
>
[Jacob Pan]
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
