INVIOLABLES.txt 4.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125
  1. The Inviolable Principles of Nuttx
  2. ==================================
  3. These are properties of NuttX that we can be certain of for all time:
  4. Definition
  5. ----------
  6. *in·vi·o·la·ble*
  7. /inˈvīələbəl/
  8. adjective
  9. adjective: inviolable
  10. never to be broken, infringed, or dishonored.
  11. "an inviolable rule of chastity"
  12. synonyms: inalienable, absolute, untouchable, unalterable,
  13. unchallengeable, unbreakable, impregnable; sacrosanct,
  14. sacred, holy, hallowed; rare intemerate
  15. "the inviolable right to life"
  16. Source: Oxford Dictionary of the English Language
  17. Strict POSIX compliance
  18. -----------------------
  19. o Strict conformance to the portable standard OS interface as defined at
  20. OpenGroup.org.
  21. o A deeply embedded system requires some special support. Special
  22. support must be minimized.
  23. o The portable interface must never be compromised only for the sake of
  24. expediency.
  25. o Expediency or even improved performance are not justifications for
  26. violation of the strict POSIX interface
  27. Modular Architecture
  28. --------------------
  29. o The internal modular architecture of the OS must maintained.
  30. o This means formalizing and documenting all internal interfaces (in the
  31. porting guide), minimal use of global variables at the interface, and
  32. only well defined functional interfaces.
  33. Clear, Consistent, Standardized Coding Style
  34. --------------------------------------------
  35. o Strict conformance to the NuttX coding style. No "revolutionary"
  36. changes to the coding standard (but perhaps some "evolutionary"
  37. changes).
  38. o Personal or organizational preference is not a justification for a
  39. coding style change.
  40. o Nothing can come into NuttX that does not follow the coding standard.
  41. o Expediency is not a justification for violating the coding standard.
  42. The NuttX coding standard can be found here:
  43. http://www.nuttx.org/doku.php?id=documentation:codingstandard
  44. Open and Unencumbered License
  45. -----------------------------
  46. o Currently BSD 3-clause or compatible: BSD 3-clause with constraints,
  47. BSD 3 and 4 clause, MIT, public domain
  48. o Other unencumbered licenses such as Apache may be considered
  49. NuttX will never be licensed under a restrictive, "Copyleft" license.
  50. All Users Matter
  51. ----------------
  52. o All support must apply equally to all supported platforms. At present
  53. this includes Linux, Windows MSYS, Windows Cygwin, Windows Ubuntu,
  54. Windows native, macOS, Solaris, and FreeBSD. No tool/environment
  55. solutions will be considered that limit the usage of NuttX on any of
  56. the supported platforms.
  57. o Inclusive rather than exclusive
  58. o Hobbyists are valued users of the OS including retro computing hobbyists
  59. * and DIY “Maker” hobbyists.
  60. o Supported toolchains: GCC, Clang, SDCC, ZiLOG ZDS-II (c89), IAR.
  61. Others?
  62. o No changes to build system should limit use of NuttX by any user.
  63. o Simplifying things for one user does not justify excluding another user.
  64. o We should seek to expand the the NuttX user base, not to limit it for
  65. reasons of preference or priority.
  66. o We must resist the pull to make NuttX into a Linux-only, GCC-only, and
  67. ARM-only solution.
  68. NuttX Branding
  69. --------------
  70. o The official name of authentic Nuttx will always be "NuttX"
  71. o This name is trademarked and may not be used by other OSs or forks of
  72. NuttX
  73. The Enemies
  74. ===========
  75. No Short Cuts
  76. -------------
  77. o Doing things the easy way instead of the correct way.
  78. o Reducing effort at the expense of Quality, Portability, or
  79. Consistency
  80. o Focus on the values of the organization, not the values of the Open
  81. Source project. Need to support both.
  82. o It takes work to support the Inviolables. There are no shortcuts.
  83. Sometimes Code Duplication is OK
  84. --------------------------------
  85. o Sometimes is better to duplicate some logic than to introduce coupling
  86. Keep the Big Picture
  87. --------------------
  88. o Too much focus on solving the problem in hand, loss of the Big Picture
  89. o Insufficient understanding of the architectural principles.
  90. Conform to Standards
  91. --------------------
  92. o Changing things only to suite a personal or organizational preference
  93. o Inflexibility, Inability to adapt
  94. o Not Invented Here (NIH) syndrome