Extend the PMIx_Tool support

[rhc54]

Initial work on the corresponding buffer ops

[rhc54]

@dsolt @artpol84 This has the required changes to support the tool extensions. It includes:

Replace enum definitions with #define to allow 3rd party extensions

Per telecon, redefine the rank as uint32 - give it a dedicated typedef in case there are any future changes.

Add new pmix_query_t data type and modify PMIx_Query API to accept it.

Add pack/unpack support for persistence, scope, range, command, info directives, data array, and query data types.

All compiles - pack/unpack support for data array is not complete, but header files appear complete

Please provide any comments/suggestions re the pmix_common.h header changes.

[rhc54]

Refs pmix/RFCs#10

[rhc54]

@artpol84 Looks like there is some cross-build contamination going on:

07:05:06 aclocal: error: config/autogen_found_items.m4:40: file 'src/mca/pdl/configure.m4' does not exist

This file is from another PR and has nothing to do with this one.

[artpol84]

bot:retest

[rhc54]

@artpol84 @karasevb I had to update the dstor interfaces to use the new pmix_rank_t data type - please check to ensure it doesn't cause a problem.

[dsolt]

I notice that when calling PMIx_Query_info and I want to query PMIX_QUERY_NAMESPACE, I am really querying a key, but I pass in an info because that is what PMIx_Query_Info takes. However, I do not bother to set up the value portion of this since I expect the value to get filled in by the call, however this leads to pack failures because PMIx_Query_Info tries to send my info with uninitialized value portion. Any thoughts on this? Am I just being lazy and I should initialize the value field's type at least or should pack not complain if the type is garbage? I don't think PMIx_Query_info can fill in the value for me because maybe there are some types of queries (someday) where the PMIx_Info is both an IN and and OUT parameter (mmmm... hungry for IN-n-OUT burger now)

[rhc54]

Oh, that is cruel - we don’t have an IN-n-OUT here, and I’ve sorely missed them. Positive thing is that they opened one about a 3hr drive away, and my wife an I are planning a trip just for lunch!

That was one motivation for dumping the blocking version of this call. I'd suggest transitioning to the non-blocking version to eliminate this problem.

Please review/approve this RFC so we can do so! 😄

[dsolt]

I am using the non-blocking version of the call right now, but either way one will have this problem of packing these PMIx_Info's. Doing some more testing today and then will approve. We got in-n-out in TX a few years ago... its is awesome.

[rhc54]

The type of the returned info is set by the library - you only pass in directives and keys stipulating what should be found.

[dsolt]

Ok, well then I think it is a problem as is because it tries to pack the Info to send up to the server and fails if the type is garbage. I don't know if we have to fix this now though.

[rhc54]

I really don't understand - are you talking about directives that modify the queries? If so, then yes, of course you have to provide the type. But if you are talking about the keys - there is no "type", it's just a char**.

[dsolt]

Ah, nevermind. I was looking at my copy which still had the old API for query. The new Query API uses pmix_query_t's instead of PMIx_Info's. Ok, also had a chance to review this code more carefully and it looks good to me.

[dsolt]

Oh I forgot to ask, what is the reason for going from enums to pound defines on many things? By the way, I skimmed the bufferops code pretty lightly. That buffer packing/unpacking code is pretty dull, but didn't notice anything that looked wrong.

[rhc54]

If we use enums, then 3rd party adopters cannot extend the definitions. So if someone wanted, for example, to support a scope that wasn't in our definitions, they couldn't do it without modifying the library.

Using pound defines allows someone to pass any value - the library isn't looking at it anyway. We just pass it thru. So if the RM can understand it, then it's okay. On another system, the user would just get a "not supported" error, but that's also okay.