search

openshmem-org / tests-sos

Sandia OpenSHMEM unit tests and performance testing suite
Other
5 stars 10 forks source link

shmem_team_ptr versioning question #39

Open ronawho opened 2 months ago

ronawho commented 2 months ago

I think shmem_team_ptr is slated for the OpenSHMEM 1.6 spec, but it's included in the test suite by default and in the v1.5.2 release. Just wondering if this is intentional or if this should somehow be opt-in or under an --enable-future configure flag or something.

davidozog commented 2 months ago

If I recall correctly, this was an intentional bit of "corner-cutting" on the SOS side, the logic being that because shmem_team_ptr seems quite likely to be ratified, we skipped our usual process of placing APIs like this in the shmemx interface until after ratification.

@ronawho - Do you think placing the shmem_team_ptr test (and tests like this going forward) in the shmemx directory be sufficient on your end, or would it be better to add a configure time flag for upcoming features? I think shmemx is currently more portable across implementations; on the other hand, I also think there could be value in creating a separate category/directory for APIs that are (very likely) soon-to-be ratified. We could potentially reduce a bit of development overhead if such tests kept the shmem_ prefix so it could quickly be supported at ratification time.

ronawho commented 2 months ago

I agree that future or soon-to-be ratified directory would probably reduce development churn. I also think that would enable other vendors to test future APIs without having to filter out any SOS specific shmemx extensions.

But no strong preference, especially with how small 1.6 is likely to be in terms of new APIs.