hal: Fix constructor signature and remove rtapi_app's access to private HAL API - #4280
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR updates the constructor signature for
constructablemodules (rtapi_app'snewinstcommand). Note that constructable modules are highly experimental, completely untested and not readily accessible by normal users.There are no in-tree components that use the construct and the mailing list has been silent. It is assumed to be a dormant feature never fully developed. It can therefore be assumed that the
newinstconstruct has no users. It is inaccessible from halcmd and needs direct rtapi_app interaction to be activated.Regardless, the old code was problematic because the constructor signature was lacking const in its arguments and rtapi_app used private HAL APIs to achieve its goal. This is no longer allowed and the construction needs to be inside the HAL library with a proper call from rtapi_app. Both problems are fixed.
Changing the constructor signature should not be a problem considering it is only accessible by being a very experimentation happy user. We already require recompilation on many of the committed changes. This is no different.
The PR moves the already exposed function from hal_lib_extra.c into hal_lib.c so that it (easily) can become part of the RT HAL library, which is a requirement for the call from rtapi_app because of the dynamic load.