Task IF refactoring #636
These changes were tested on all OSALs. The FreeRTOS and RTEMS updates wered tested in the FSFW example for the STM32H7. The Linux changes were tested in the EIVE fork.
The hosted changes were tested in the hosted FSFW example.
Also, some other general improvements/notes:
There seems to be a concensus that virtual functions should not have default arguments. See https://google.github.io/styleguide/cppguide.html#Default_Arguments
The defaults for arguments in a virtual function call are determined by the static type of the target object, and there's no guarantee that all overrides of a given function declare the same defaults.
and this stack overflow post https://www.google.com/search?channel=fs&client=ubuntu&q=default+arguments+on+virtual+or+override+methods+are+prohibited .
clang-tidy recommends adding
[[nodiscard]] to all constant getters.
For me, this seems to be a reasonable action. It can prevent missed returnvalue checks and useless getter function calls. If someone decides to actively ignore a returnvalue, they can explicitely cast the function call to void to avoid the warning.
Also, it might be a good idea to compile the FreeRTOS and RTEMS OSALs in the CI/CD as well. It should be possible to create a docker container which has all necessary tools pre-installed.
Refactoring general task code
- There was a lot of duplicate/boilerplate code inside the individual task IF OSAL implementations. Remove it by introducing base classes
- A lot of
virtual ReturnValue_t addComponent(object_id_t object)to
virtual ReturnValue_t addComponent(object_id_t object, uint8_t opCode = 0), allowing to pass the operation code passed to
performOperation. Update API taking an
- Add additional
addSlotfunction which takes an
ExecutableObjectIFpointer and its Object ID
- Introduce typedef
ReturnValue_t (*customCheckFunction)(const SlotList&).
ReturnValue_t (*customCheckFunction)(const SlotList&)to
ReturnValue_t (*customCheckFunction)(const SlotList&, void*), allowing arbitrary user arguments
for the custom checker
- Use composition instead of inheritance for the
PeriodicPosixTaskand make the
PosixTaska member of the class
I would prefer a bitmore vocal name for
As you can see from me nitpicking naming conventions, no bigger issues from my side ;)
No due date set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?