@wdamon-intel : I think we can do this w/o problems. we have the ones for memory, we could add the ones for pools, following the same semantics and meaning. this should be easy to do for v1.8.

@zzdanowicz please check #220

Moving out of v1.8 Release. Offline review highlighted a need for further discussion.

We had a discussion on this and IPC should remain opaque, so any API's that expose internal handles / OS details shouldn't be added.

So adding that two functions to strip wanted data out of opaque handles is justified.

no , as it would make IPC not opaque.

Retrieving data from opaque handler by dedicated function is making handler not opaque? We do not reveal memory layout that can change and sounds like contradiction to me - can you expand your thinking?

to keep it opaque we should never return any handle via any APIs

So retrieving via API call partial data from opaque handler is not an option? OK, but right now applications are stripping that data directly - this is much worse as driver can change memory layout of the opaque handler and applications would break. With these at least the driver allows for some control over applications.

yes what is now is much worse, but this is due to the fact that IPC is not opaque.
The solution is not to add more API's that return implementation details, but rather make ipc_handles truly opaque and whenever you use IPC you just use IPC opaque structures and nothing else.
And yes exposing handles requires underlying implementation to implement IPC using single handle, which reveals' the implementation details and solidifies it.