123 lines
4.1 KiB
Plaintext
123 lines
4.1 KiB
Plaintext
|
The Inviolable Principles of Nuttx
|
|||
|
|
==================================
|
|||
|
|
|
|||
|
|
These are properties of NuttX that can be certain of for all time
|
|||
|
|
|
|||
|
|
Definition
|
|||
|
|
----------
|
|||
|
|
|
|||
|
|
*in·vi·o·la·ble*
|
|||
|
|
/inˈvīələbəl/
|
|||
|
|
|
|||
|
|
adjective
|
|||
|
|
adjective: inviolable
|
|||
|
|
|
|||
|
|
never to be broken, infringed, or dishonored.
|
|||
|
|
|
|||
|
|
"an inviolable rule of chastity"
|
|||
|
|
|
|||
|
|
synonyms: inalienable, absolute, untouchable, unalterable,
|
|||
|
|
unchallengeable, unbreakable, impregnable; sacrosanct,
|
|||
|
|
sacred, holy, hallowed; rare intemerate
|
|||
|
|
|
|||
|
|
"the inviolable right to life"
|
|||
|
|
|
|||
|
|
Source: Oxford Dictionary of the English Language
|
|||
|
|
|
|||
|
|
Strict POSIX compliance
|
|||
|
|
-----------------------
|
|||
|
|
|
|||
|
|
o Strict conformance to the portable standard OS interface as defined at
|
|||
|
|
OpenGroup.org.
|
|||
|
|
o A deeply embedded system requires some special support. Special
|
|||
|
|
support must be minimized.
|
|||
|
|
o The portable interface must never be compromised only for the sake of
|
|||
|
|
expediency.
|
|||
|
|
o Expediency or even improved performance are not justifications for
|
|||
|
|
violation of the strict POSIX interface
|
|||
|
|
|
|||
|
|
Modular Architecture
|
|||
|
|
--------------------
|
|||
|
|
|
|||
|
|
o The internal modular architecture of the OS must maintained.
|
|||
|
|
o This means formalizing and documenting all internal interfaces (in the
|
|||
|
|
porting guide), minimal use of global variables at the interface, and
|
|||
|
|
only well defined functional interfaces.
|
|||
|
|
|
|||
|
|
Clear, Consistent, Standardized Coding Style
|
|||
|
|
--------------------------------------------
|
|||
|
|
|
|||
|
|
o Strict conformance to the NuttX coding style. No "revolutionary"
|
|||
|
|
changes to the coding standard (but perhaps some "evolutionary"
|
|||
|
|
changes).
|
|||
|
|
o Personal or organizational preference is not a justification for a
|
|||
|
|
coding style change.
|
|||
|
|
o Nothing can come into NuttX that does not follow the coding standard.
|
|||
|
|
o Expediency is not a justification for violating the coding standard.
|
|||
|
|
|
|||
|
|
Open and Unencumbered License
|
|||
|
|
-----------------------------
|
|||
|
|
|
|||
|
|
o Currently BSD 3-clause or compatible: BSD 3-clause with constraints,
|
|||
|
|
BSD 3 and 4 clause, MIT, public domain
|
|||
|
|
o Other unencumbered licenses such as Apache may be considered
|
|||
|
|
NuttX will never be licensed under a restrictive, "Copyleft" license.
|
|||
|
|
|
|||
|
|
All Users Matter
|
|||
|
|
----------------
|
|||
|
|
|
|||
|
|
o All support must apply equally to all supported platforms. At present
|
|||
|
|
this includes Linux, Windows MSYS, Windows Cygwin, Windows Unbuntu,
|
|||
|
|
Windows native, macOS, Solaris, and FreeBSD. No tool/environment
|
|||
|
|
solutions will be considered that limit the usage of NuttX on any of
|
|||
|
|
the supported platforms.
|
|||
|
|
o Inclusive rather than exclusive
|
|||
|
|
o Hobbyists are valued users of the OS including retro computing hobbyists
|
|||
|
|
* and DIY “Maker” hobbyists.
|
|||
|
|
o Supported toolchains: GCC, Clang, SDCC, ZiLOG ZDS-II (c89), IAR.
|
|||
|
|
Others?
|
|||
|
|
o No changes to build system should limit use of NuttX by any user.
|
|||
|
|
o Simplifying things for one user does not justify excluding another user.
|
|||
|
|
o We should seek to expand the the NuttX user base, not to limit it for
|
|||
|
|
reasons of preference or priority.
|
|||
|
|
o We must resist the pull to make NuttX into a Linux-only, GCC-only, and
|
|||
|
|
ARM-only solution.
|
|||
|
|
|
|||
|
|
NuttX Branding
|
|||
|
|
--------------
|
|||
|
|
|
|||
|
|
o The official name of authentic Nuttx will always be "NuttX"
|
|||
|
|
o This name is trademarked and may not be used by other OSs or forks of
|
|||
|
|
NuttX
|
|||
|
|
|
|||
|
|
The Enemies
|
|||
|
|
===========
|
|||
|
|
|
|||
|
|
No Short Cuts
|
|||
|
|
-------------
|
|||
|
|
|
|||
|
|
o Doing things the easy way instead of the correct way.
|
|||
|
|
o Reducing effort at the expense of Quality, Portability, or
|
|||
|
|
Consistency
|
|||
|
|
o Focus on the values of the organization, not the values of the Open
|
|||
|
|
Source project. Need to support both.
|
|||
|
|
o It takes work to support the Inviolables. There are no shortcuts.
|
|||
|
|
|
|||
|
|
Sometimes Code Duplication is OK
|
|||
|
|
--------------------------------
|
|||
|
|
|
|||
|
|
o Sometimes is better to duplicate some logic than to introduce coupling
|
|||
|
|
|
|||
|
|
Keep the Big Picture
|
|||
|
|
--------------------
|
|||
|
|
|
|||
|
|
o Too much focus on solving the problem in hand, loss of the Big Picture
|
|||
|
|
o Insufficient understanding of the architectural principles.
|
|||
|
|
|
|||
|
|
Conform to Standards
|
|||
|
|
--------------------
|
|||
|
|
|
|||
|
|
o Changing things only to suite a personal or organizational preference
|
|||
|
|
o Inflexibility, Inability to adapt
|
|||
|
|
o Not Invented Here (NIH) syndrome
|