From b8a47f9b0f5cb5e50e87b6e8abbcbc300409e656 Mon Sep 17 00:00:00 2001 From: Gregory Nutt Date: Wed, 14 Feb 2018 14:17:44 -0600 Subject: [PATCH] Documentation: Minor improve to improve readability of text. --- Documentation/NuttxPortingGuide.html | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/Documentation/NuttxPortingGuide.html b/Documentation/NuttxPortingGuide.html index cecaaef7b9..7aeb146db1 100644 --- a/Documentation/NuttxPortingGuide.html +++ b/Documentation/NuttxPortingGuide.html @@ -1569,8 +1569,8 @@ The specific environmental definitions are unique for each board but should incl Header files are made accessible to internal OS logic and to applications through symbolic links and through include paths that are provided to the C/C++ compiler. Through these include paths, the NuttX build system also enforces modularity in the design. For example, one important design principle is architectural layering. - In this case I am referring to the OS as layered in to application interface, common internal OS logic, and lower level platform-specific layers. - The platform-specific layers all reside in the either arch/ sub-directorories on the config/ subdirectories: The former sub-directories are reserved for microcontroller-specific logic and the latter for board-specific logic. + In this case I am referring to the OS as layered into application interface, common internal OS logic, and lower level platform-specific layers. + The platform-specific layers all reside in the either arch/ sub-directories on the config/ subdirectories: The former sub-directories are reserved for microcontroller-specific logic and the latter for board-specific logic.

In the strict, layered NuttX architecture, the upper level OS services are always available to platform-specific logic. However, the opposite is not true: Common OS logic must never have any dependency on the lower level platform-specific code. The OS logic must be totally agnostic about its hardware environment. Similarly, microcontroller-specific logic was be completely ignorant of board-specific logic. @@ -1583,8 +1583,10 @@ The specific environmental definitions are unique for each board but should incl Similarly, the board-specific include directory will be linked at include/arch/board and, hence, can be included like #include <arch/board/board.h.

- Keeping in the spirit of the layered architecture, this publicly visible header files must not export platform-specific definitions; Only standardized definitions should be visible such as those provided in include/nuttx/arch.h or include/nuttx/board.h. - And, similarly, these publicly visible header file must not include files that reside in the inaccessible platform-specific source directories. + Keeping in the spirit of the layered architecture, these publicly visible header files must not export platform-specific definitions; Only platform-specific realizations of standardized declarations should be visible. + Those standardized declarations should appear in common header files such as those provided by include/nuttx/arch.h and include/nuttx/board.h. + Similarly, these publicly visible header file must not include files that reside in the inaccessible platform-specific source directories. + For example, the board-specific configs/<board>/include/board.h header file must never include microcontroller-specific header files that reside in arch/<arch>/src/. That practice will cause inclusion failures when the publicly visible file is included in common logic outside of the platform-specific source directories.