From 1b325342f450230dca5a2b9ed05818e5a7676c13 Mon Sep 17 00:00:00 2001 From: Matthew Koch Date: Sun, 17 Mar 2019 19:42:44 +0000 Subject: [PATCH] Merged in mjkoch/nuttx/mjkoch (pull request #841) Correct a few tpyos Approved-by: Gregory Nutt --- arch/README.txt | 22 +++++++++++----------- drivers/README.txt | 13 +++++++------ fs/binfs/fs_binfs.c | 2 +- pass1/README.txt | 2 +- 4 files changed, 20 insertions(+), 19 deletions(-) diff --git a/arch/README.txt b/arch/README.txt index 3b26ac50b03..51bccd4ad56 100644 --- a/arch/README.txt +++ b/arch/README.txt @@ -43,10 +43,10 @@ arch//arch.h as described below). Directory Structure ^^^^^^^^^^^^^^^^^^^ -The arch directory contains architecture specific logic. The complete -board port in is defined by the architecture-specific code in this -directory (plus the board-specific configurations in the config/ -subdirectory). Each architecture must provide a subdirectory +The arch/ directory contains architecture-specific logic. The complete +board port is defined by the architecture-specific code in this +directory plus the board-specific configurations in the config/ +subdirectory. Each architecture must provide a subdirectory under arch/ with the following characteristics: @@ -81,16 +81,16 @@ include/types.h _int8_t, _uint8_t, _int16_t, _uint16_t, _int32_t, _uint32_t - and if the architecture supports 64-bit integers. + and if the architecture supports 64-bit integers: - _int24_t, _uint24_t, int64_t, uint64_t + _int24_t, _uint24_t, _int64_t, _uint64_t NOTE that these type names have a leading underscore character. This file will be included(indirectly) by include/stdint.h and typedef'ed to the final name without the underscore character. This roundabout way of doings things allows the stdint.h to be removed from the include/ directory in the event that the user prefers to use the definitions - provided by their toolchain header files + provided by their toolchain header files. irqstate_t @@ -101,10 +101,10 @@ include/types.h available to all files. include/irq.h - This file needs to define some architecture specific functions (usually - inline if the compiler supports inlining) and structure. These include: + This file needs to define some architecture-specific functions (usually + inline if the compiler supports inlining) and structures. These include: - - struct xcptcontext. This structures represents the saved context + - struct xcptcontext. This structure represents the saved context of a thread. - irqstate_t up_irq_save(void) -- Used to disable all interrupts. @@ -113,7 +113,7 @@ include/irq.h enables to the same state as before up_irq_save was called. NOTE: These interfaces are not available to application code but can - only be used withint the operating system code. And, in general, + only be used within the operating system code. And, in general, these functions should *never* be called directly, not unless you know absolutely well what you are doing. Rather you shoudl typically use the wrapper functions enter_critical_section() and leave_critical_section() diff --git a/drivers/README.txt b/drivers/README.txt index e882afec297..0db08757cd1 100644 --- a/drivers/README.txt +++ b/drivers/README.txt @@ -12,11 +12,11 @@ Contents: Files in this directory ^^^^^^^^^^^^^^^^^^^^^^^ -dev_null.c, dev_urandom, and dev_zero.c - These files provide the standard /dev/null, /dev/urandom, and /dev/zero - devices. See include/nuttx/drivers/driers.h for prototypes of functions - that should be called if you want to register these devices - (devnull_register(), devurandom_register(), and devzero_register()). +dev_null.c and dev_zero.c + These files provide the standard /dev/null and /dev/zero devices. See + include/nuttx/drivers/driers.h for prototypes of functions that should + be called if you want to register these devices (devnull_register() + and devzero_register()). ramdisk.c Can be used to set up a block of memory or (read-only) FLASH as @@ -56,7 +56,8 @@ contactless/ to contactless cards and tags. crypto/ - Contains crypto drivers and support logic. + Contains crypto drivers and support logic, including the /dev/urandom + device. eeprom/ An EEPROM is a form of Memory Technology Device (see drivers/mtd). diff --git a/fs/binfs/fs_binfs.c b/fs/binfs/fs_binfs.c index 2d273432d5d..7e365759352 100644 --- a/fs/binfs/fs_binfs.c +++ b/fs/binfs/fs_binfs.c @@ -161,7 +161,7 @@ static int binfs_open(FAR struct file *filep, FAR const char *relpath, index = builtin_isavail(relpath); if (index < 0) { - ferr("ERROR: Builting %s does not exist\n", relpath); + ferr("ERROR: Built-in %s does not exist\n", relpath); return -ENOENT; } diff --git a/pass1/README.txt b/pass1/README.txt index 9e3e2f64765..d0453ceae8b 100644 --- a/pass1/README.txt +++ b/pass1/README.txt @@ -7,7 +7,7 @@ README In the two pass build, the application logic is built during the first phase, pass 1. In that phase, the application may generate and install - source files in the pass1/directory. + source files into the pass1/ directory. The operating system is built during phase 2 of the build. At that time, those source files in the pass1/ directory will be built and incorporated