-
Notifications
You must be signed in to change notification settings - Fork 204
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CFE RELOAD and RESTART commands handled (almost) identically #793
Comments
Checking the requirements -- cES1007 doesn't say one way or the other:
But functional requirement cES1007.2 says:
Which seems weird, if the intent is that the restart command doesn't reload the file. The code also fails this requirement, as the "restart" command doesn't check for the existence of the file, only the "reload" command does this, even though they currently both unload/reload the code module from disk. |
No futher details exist in the internal requirements management system. But I read the difference as being RELOAD is intended to be a different file name (app name and file name parameters in command), where-as RESTART uses the same information as when originally started (only takes app name). cES1007 - RESTART rationale:
cES1008 - RELOAD ratonale:
For cES1007.2 - we recently updated the rationale
Edit - just updated the rationale that used to say the app would continue without a restart |
Looks to me like the header file documentation is wrong. |
OK - changing the doxygen comments to reflect what the code does is certainly easier than updating the code to do what the comment says. The rationale seems lacking because, at least as written, RELOAD can cover the RESTART use-case as well as its own. Having a whole separate command to do the same thing (just minus the file name) doesn't seem necessary. But since it already exists I suppose we can leave it. |
Agreed, reload with empty filename could use original or similar. Maybe a quick refactor under the hood to avoid code duplication? If it's easy. Processing really should be the same code I'd think. |
It is already consolidated where possible. Although it is nearly identical -- there are a dedicated/different set of event IDs -- same meaning, different numbers, and the text says "restart" or "reload" within the message too. So there is dedicated code to handle the command, and dedicated code to send completion events, but everything in the middle uses common functions. Again, although the event meanings are also identical, they have different IDs and different text. So to further clean it up/consolidate it would be matter of removing "restart" entirely but I'm not necessarily advocating for that right now as it impacts requirements and ground system etc. It is definitely easier to just update the doxygen comments and leave the two commands in place. |
Fix #793, Clarify restart/reload app behavior
Describe the bug
The documentation of the
CFE_ES_RESTART_APP_CC
specifically says here that it is not reloaded from the disk file:cFE/fsw/cfe-core/src/inc/cfe_es_msg.h
Line 324 in 5ac3f0a
But in the way the code has evolved, both RELOAD and RESTART control requests end up going through
CFE_ES_CleanUpApp()
function:cFE/fsw/cfe-core/src/es/cfe_es_apps.c
Lines 961 to 968 in 5ac3f0a
cFE/fsw/cfe-core/src/es/cfe_es_apps.c
Lines 997 to 1003 in 5ac3f0a
Notably, the
CFE_ES_CleanUpApp()
function will, in fact, unload the module viaOS_ModuleUnload()
, and the subsequentCFE_ES_AppCreate()
function will load it again from disk. Also important that the AppID might change too as part of this process, which may or may not be expected?Expected behavior
Should make the documentation and code match one way or another:
CFE_ES_RESTART_APP_CC
says, we need to update this to NOT completely unload the module.CFE_ES_RELOAD_APP_CC
to warrant the existence of a separate command.Additional context
I noticed this inconsistency while doing implementation of #28. I can put in a fix for this issues as part of the same (upcoming) PR, just need CCB concurrence on which way to go - do we make it work as described, or we describe the way it works.
Reporter Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered: