You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
All the app core modules are tracked by ES, because apps all have an entry in the global app table. So one can get an ID and all other expected operations such as name/ID lookups work.
However CFE FS subsystem is not an app, it is a library. As a result, it cannot be identified/queried in any way.
To Reproduce
Call e.g. CFE_ES_GetLibIDByName(&LibId, "CFE_FS") and one will get a result of CFE_ES_ERR_NAME_NOT_FOUND, even though the CFE_FS subsystem definitely exists.
Expected behavior
The FS subsystem should be registered in the global table as a library, so it can be identified and referred to.
System observed on:
Ubuntu 20.04
Additional context
Noticed this with extended testing of #28 - queries for CFE_ES, CFE_SB, etc all work, but an attempt to query CFS_FS doesn't work, but it probably should.
Reporter Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered:
I'm not clear on the advantage of adding CFE_FS as a "library". From the build perspective all of cfe-core is a library. Each service has associated API's, all but FS have an entry point/main task. I think of FS as just an additional set of APIs. What additional capability would this enable (a name/ID lookup doesn't make much sense to me if you can't do anything with it or tell it apart from the rest of the cfe). IIRC the entire cfe gets checksummed...
Yes, this is precisely how I would define a "library" - an additional set of APIs that does not have a task associated. Whereas an app is the same thing but has at least one task, and the associated configuration of that.
CFE_FS becomes an outlier in that it has resources but there is no resource ID associated with it.
It isn't a huge deal, but the inconsistency becomes more noticeable if/when Libs also load dependent resources during their init. These are logically "owned" or associated with the library for tracking purposes. We can easily this for apps by associating the loaded resource with the appID and we can also do this for dynamically-loaded libraries because they have a libID, but CFE_FS is the oddball, it has no ID.
It's fairly trivial to do - reserve an ID for CFE_FS and associate it during startup.
Then as a result it will be included in QUERY_ONE and QUERY_ALL commands, just like ES/EVS/SB/TBL/TIME are. Admittedly there wouldn't be much useful information because its statically linked, I think it should be included in the set for consistency if nothing else.
Describe the bug
All the app core modules are tracked by ES, because apps all have an entry in the global app table. So one can get an ID and all other expected operations such as name/ID lookups work.
However CFE FS subsystem is not an app, it is a library. As a result, it cannot be identified/queried in any way.
To Reproduce
Call e.g.
CFE_ES_GetLibIDByName(&LibId, "CFE_FS")
and one will get a result ofCFE_ES_ERR_NAME_NOT_FOUND
, even though the CFE_FS subsystem definitely exists.Expected behavior
The FS subsystem should be registered in the global table as a library, so it can be identified and referred to.
System observed on:
Ubuntu 20.04
Additional context
Noticed this with extended testing of #28 - queries for CFE_ES, CFE_SB, etc all work, but an attempt to query CFS_FS doesn't work, but it probably should.
Reporter Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered: