Skip to content

Meeting 2022 04 14

Jump to bottom
Thomas Naughton edited this page Apr 14, 2022 · 5 revisions

Agenda

Attendance

Person Institution

Notes

  • PMIx v4 / v5 Brief check-ins on progress

  • Working group updates

  • Defining PMIx ABI

    • Current state of ABI captured on #365 https://github.com/pmix/pmix-standard/issues/365#issuecomment-1095650601
    • Captures items closed, and pieces to be read at next meeting
    • Description with diagram at https://github.com/pmix/pmix-abi
    • Compatibility Query raised to know what ABI the PMIx implementation support.  Rational: If tool dlopen(), may need to if function signatures change, they could check for things like changes in provisional APIs. Example program to demonstration this query.
    • ABI dlopen example https://github.com/pmix/pmix-abi/pull/10
    • Q: Should the semantics for MAJOR, MINOR details in ABI be clarified, e.g., backward compat, etc?
    • Discuss: Gets little difficult.  Only reason would not be compatible is if we changed size/structure.
    • Note: If built against different MAJOR ABI version can reason about fate, but if given a different MINOR ABI version should be able to reason about things.
    • Roughly, how do the Provisional items, and their change, interact with the MAJOR/MINOR version changes in ABI?
    • Maybe have changes in MAJOR represent changes to Stable, and changes to MINOR represent changes to Provisional items.  So could be more careful about the MINOR diffs, as needed.
    • Discussion on MINOR diffs w/ Provisional…
    • Maybe should have stable abi and provisional abi query?
    • This requires user to dig into standard, raises work on user side to capture.  Difficult to make sure capturing these things succinctly and still be useful.
    • Maybe should force renaming of things, even in Provisional items, required when revising things.  This is how OpenPMIx treats things once something is released to maintain compatibility for all users.
    • A new ABI change would then require a new name
    • Unsure how to provide the query info back in a confident way to ensure info is reliable.
    • Should we include the MAJOR / Stable items in a release of the standard so it is clear what is stable/provisional for a given snapshot of the standard, which would flow down to ABI
    • Maybe have ABI only include Stable items, and not include Provisional items in ABI, to include ignoring Provisional in the query.  Idea being to defer dealing w/ provisional to future.
    • Challenge is that if you add something to Provisional, often to get the bleeding edge items working and that is why there is pressure to get something into standard.  I.e., fixes needed by active uses are what drive additional the Provisional items.
    • Maybe naming is bad, but idea of MAJOR (first) convey something changed and MINOR (second) indicates additive.  Example: First number changes indicates things break.
    • Basically converging on the Libtool rules, https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
      • Current[:revision[:age]]
      • e.g., --version-info 3:12:1 current=3, revision=12, age=1
    • Possibly change wording to match
    • Seems like may need to treat Provisional separately, likely having separate queries for stable/provisional.  However, the same logic applied to Provisional, possibly changing more frequently, but clear and avoids blanket changes falling between cracks or being difficult to understand if was Stable or Provisional change.
    • Can you also include support for ranges of support, e.g., implementation that continues to support removed items to aid users.  Possibly a “set” of versions that are supported.
    • Note: If going to modify something in standard should rename them.  Think there is wording in standard for this scenario (i.e., should not be doing rename, but instead rename).
    • But for query interface, having result a comma separate list of “supported” version would be useful.  Also these would be separate for Stable & Provisional.

  • Discussion about pmix_value_t structure, gist being padding or other changes will be architecture specific.  Having that padding in the standard is likely not useful.  Padding seems like more of an implementation detail.

Home

Working Groups

Events

Helpful How To...

ASC Quarterly Meetings

ASC Monthly Meetings

Clone this wiki locally