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
It has come to our attention that the documentation lacks the necessary precision and depth that developers require for autonomous integration and implementation. Reverse engineer what we did should be the fallback, not the default.
I propose an enrichment of the documentation to include the following:
detailed descriptions of each function. They should be accompanied by a comprehensive description, outlining not only its purpose but also any subtleties in its behavior or usage. Referring to Posix or assuming the developers are familiar with Posix won't be enough and could slow down the adoption. The best example is select() implementation which only needs to support sockets. It needs to be very explicit about the block or non-blocking nature of each API.
detail description of each constant, including error codes and priorities.
a contribution guide and/or a developer starting guide could also be helpful. It could detail where to create what and summarize the discussions we had about the osal/ directory organization.
The text was updated successfully, but these errors were encountered:
It has come to our attention that the documentation lacks the necessary precision and depth that developers require for autonomous integration and implementation. Reverse engineer what we did should be the fallback, not the default.
I propose an enrichment of the documentation to include the following:
The text was updated successfully, but these errors were encountered: