Add OS_QueueGetName()

[CDKnightNASA]

Is your feature request related to a problem? Please describe.
cFE will have a function to get a pipe's name given its id, which will call down to OSAL to get the name from the queue. Currently this is accomplished with OS_QueueGetInfo() but that requires a pointer to a struct buffer.

Describe the solution you'd like
A convenience function should be added to retrieve a queue's name given its id without the need to pass in a struct buffer (instead passing in a string buffer.)

Describe alternatives you've considered
Could maintain the status quo, this is a convenience function.

Additional context
Add any other context about the feature request here.

Requester Info
Christopher.D.Knight@nasa.gov

[jphickey]

This function should be generic and not queue-specific. Propose the following API:

int32 OS_GetResourceName(uint32 id, char *buffer, uint32 buffer_size)

This should be able to get the name of any resource (queue, task, semaphore, file, etc).

[CDKnightNASA]

Agreed, in fact should this ticket be to generalize all of the OSAL functions that interact with queues, tasks, etc.? Of course the "depricated" calls would just be simple wrappers for the generic calls.

[jphickey]

I think the only other item which is common to all resources is the "creator" (i.e. the task ID of the calling context when the resource was allocated/opened).

But unless there is a good reason to expose that individually, I think we should just do the name for now.

[CDKnightNASA]

This function should be generic and not queue-specific. Propose the following API:

int32 OS_GetResourceName(uint32 id, char *buffer, uint32 buffer_size)

This should be able to get the name of any resource (queue, task, semaphore, file, etc).

Hmm, so I'm considering this but it seems that all of the code underpinning these functions is expecting type information (such as OS_ObjectIdToArrayIndex(uint32 idtype...)). This would either necessitate re-writing all of these functions to allow for passing in a "any type" parameter or making parallel functions that do not require type. Thoughts?

[jphickey]

As you noted, most current OSAL code uses the "idtype" in an enforcing mode, that is it knows what type the object is supposed to be, and it enforces that the passed-in id matches the expected type.

All the existing use-cases are in that mode, because last-gen OSAL used a zero-based ID for all object types, and you had to know what type of object you were dealing with first.

The notion of a generic function that works on all types is only possible now that the last-gen OSAL is retired, and the external id values are all uniquely identifiable.

There are two options to implement this:

Quick and dirty: just do (id >> OS_OBJECT_TYPE_SHIFT) to get the idtype, and pass that into OS_ObjectIdGetById(). The enforcement checks will pass.

More complete/thorough: Add a new helper function to get the object type from the id (which can be public). Define the idtype of 0 to be "any" (make a new constant) and modify the existing functions, where relevant, to not error out if the passed-in idtype is this value. It may not applicable everywhere, however, for instance the ObjectIdGetByName() might be an issue as we only ensure unique names within a single object type. Likewise the OS_GetBaseForObjectType() internal helper function needs to operate on a real (specific) object type.

[skliper]

Removed milestone since this is not critical to certification. Still fine to work it, just at a lower priority.

[jphickey]

FYI - This was implemented a while ago - the function is OS_GetResourceName() and it was in fixed in #469

This can be used to get the name of any object, including queues. Closing this ticket, please reopen if there is something else we need.

[skliper]

Just open/close so I can link to PR.