Hi Paolo + all,
First off, thanks for your ongoing RCU work, which I'm closely
following.
As you stated in the initial RCU patch (7911747b), the intent
is to keep the same API as liburcu's. I checked whether this
was the case and found a couple of issues that I'm addressing
in the appended series.
* The first two patches bring back the RCU API to exactly
match that of liburcu.
* The third patch adds a configure flag to choose from either
liburcu or QEMU's RCU.
Apart from this, I wonder what to do about other valuable bits in
liburcu, particularly in liburcu-cds, which I'm using currently
off-tree. I see three ways of eventually doing this:
a) Add Windows support in liburcu, thereby eliminating the
de facto fork in QEMU.
b) Bring (fork) liburcu-cds to QEMU, just like liburcu-mb was.
c) Add a compile-time flag (say CONFIG_LIBURCU_CDS), and then only
use data structures from liburcu-cds where appropriate, falling
back to traditional locked structures when !CONFIG_LIBURCU_CDS.
Currently I'm using c) because I cannot do either a) and b)--I
don't know anything about Windows and have no need for it.
Would c) be acceptable for upstream, provided the gains (say in
scalability/memory footprint) are significant?
Thanks,
Emilio
