On Tue, Sep 22, 2026 at 10:04:39PM +0800, Peng Fan wrote:
quoted
... and slightly mentions "simplifies". Maybe it should write about
why this is necessary and how xarray would simplify vs RB tree?
Jean had a comment that "maybe simplify the driver first by moving to a xarray",
see [1] [2].
[1] https://lore.kernel.org/linux-iommu/20230518130459.GA2587493@myrica/ (local)
[2] https://lore.kernel.org/linux-iommu/ecb3725c-27c4-944b-b42c-f4e293521f94@arm.com/#t (local)
You should have put a suggested-by tag and likely one of the links
as well.
With that being said, I don't see the reasoning in those emails very
convincing either. I don't dislike xarray. Yet in this series, there
seems no compelling reason on switching RB tree to xarray.
A subsequent patch needs to look up an existing stream by SID and
then decide to share it rather than reject it - two separate
operations. The RB tree's rb_find_add() fuses lookup and insertion
atomically: it either inserts or returns the collision, making
"find, then conditionally share" impossible without restructuring.
XArray's xa_load() and xa_store() are independent operations that
naturally support this pattern.
If you avoid duplicated stream structures as I suggested in PATCH-2,
there is no need of that, since you would only insert once to the RB
tree.
Nicolin