Hi Mathieu,
On 8/10/22 10:13 PM, Mathieu Desnoyers wrote:
----- On Aug 9, 2022, at 5:38 PM, Sean Christopherson seanjc@xxxxxxxxxx wrote:
On Tue, Aug 09, 2022, Mathieu Desnoyers wrote:
----- On Aug 9, 2022, at 8:21 AM, Mathieu Desnoyers
mathieu.desnoyers@xxxxxxxxxxxx wrote:
[...]
All those are handled in the rseq selftests and in librseq. Why duplicate all
that logic again?
More to the point, considering that we have all the relevant rseq registration
code in tools/testing/selftests/rseq/rseq.c already, and the relevant thread
pointer getter code in tools/testing/selftests/rseq/rseq-*thread-pointer.h,
is there an easy way to get test applications in tools/testing/selftests/kvm
and in tools/testing/selftests/rseq to share that common code ?
Keeping duplicated compatibility code is bad for long-term maintainability.
Any reason not to simply add tools/lib/rseq.c and then expose a helper to get
the
registered rseq struct?
Indeed, moving rseq.c to tools/lib/ would allow building a .so from any selftest
which needs to use it.
And we could move the relevant rseq helper header files to tools/include/rseq/*
as well.
Thoughts ?
One question is how librseq.so can be built automatically, when I'm going to
build tools/testing/selftests/kvm/rseq_test.
# cd linux/tools/testing/selftests/kvm
# make rseq_test
It's not perfect if I have to build tools/lib/librseq.so in advance, in order
to build tools/testing/selftests/kvm/rseq_test for the sake of dependency.
Thanks,
Gavin
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm