Design motivation for the call protocol?

[hmijail]

Hello,

I'm new to ChibiOS/RT, and just read about the call protocol.

It feels a bit in the extreme side of things, so I wanted to ask about the motivation and experience with it. More concretely:
- "checks can be disabled in the deployed code" -> is that akin to disabling asserts?
- How has that call protocol worked out? Let's say, if ChibiOS had to start again, would it follow that path again? (I wonder about PoV from both OS developers and users. Is it a pleasure or pain point?)

Thank you for any insight you can provide!

[Giovanni]

Hi,

Rationale is efficiency, non-public interfaces only needs to be checked at development time, passing wrong parameters is a programming error not a normal runtime event. This is why parameters checking can be disabled in the deployed code:
- Reduced size is related to device cost.
- Improved execution efficiency is related to power usage.

Error codes are a terrible design choice IMHO, you need code to detect errors and return them, you need code after each function call to check if it returned an error, you need code to handle those errors, you need design time for the error handling strategy and you need an error handling strategy. Much better is design the system to not require passing errors around, this is what ChibiOS tries to enforce. The API is designed to not fail as long you pass correct parameters, any anomaly is detected at development time.

There are functions returning codes: MSG_OK, MSG_TIMEOUT and MSG_RESET, but those are not errors, those are the expected function outcomes.

Disabling checks is much like disabling assertions but in ChibiOS assertions and function parameters are kept separate, you can enabled/disable those independently.

Public interfaces are a different matter, the application should sanitize anything coming from the outside, directly or indirectly. It is not as simple as enabling function parameters checks.

Giovanni