diff --git a/Documentation/NuttxPortingGuide.html b/Documentation/NuttxPortingGuide.html index c188ee72d17..7ea3e39c138 100644 --- a/Documentation/NuttxPortingGuide.html +++ b/Documentation/NuttxPortingGuide.html @@ -12,7 +12,7 @@

NuttX RTOS Porting Guide

-

Last Updated: September 14, 2014

+

Last Updated: October 14, 2014

@@ -104,45 +104,69 @@ 4.3.4 Tickless OS
4.3.5 Watchdog Timer Interfaces - 4.4 Address Environments + 4.4 Work Queues - 4.5 APIs Exported by NuttX to Architecture-Specific Logic + 4.5 Address Environments - 4.6 Shared Memory + 4.6 APIs Exported by NuttX to Architecture-Specific Logic - 4.7 On-Demand Paging
- 4.8 LED Support + 4.7 Shared Memory + 4.8 On-Demand Paging
+ 4.9 LED Support + 5.0 NuttX File System
@@ -2900,7 +2924,418 @@ VxWorks provides the following comparable interface: means either that wdog is not valid or that the wdog has already expired.

-

4.4 Address Environments

+

4.4 Work Queues

+

Work Queues. + NuttX provides work queues. Work queues are threads the service a queue of work items to be performed. There are useful for off-loading work to a different threading context, for delayed processing, or for serializing activities. +

+ +

4.4.1 Classes of Work Queues

+ +

Classes of Work Queues. + There are three different classes of work queues, each with different properties and intended usage. These class of work queues along with the the common work queue interface are described in the following paragraphs. +

+ +

4.4.1.1 High Priority Kernel Work queue

+ +

High Priority Kernel Work queue. + The dedicated high-priority work queue is intended to handle delayed processing from interrupt handlers. This work queue is required for some drivers but, if there are no complaints, can be safely disabled. The high priority worker thread also performs garbage collection -- completing any delayed memory deallocations from interrupt handlers. If the high-priority worker thread is disabled, then that clean up will be performed either by (1) the low-priority worker thread, if enabled, and if not (2) the IDLE thread instead (which runs at the lowest of priority and may not be appropriate if memory reclamation is of high priority) +

+

Device Driver Bottom Half. + The higher priority worker thread is intended to serve as the bottom half for device drivers. As a consequence it must run at a very high, fixed priority rivalling the priority of the interrupt handler itself. Typically, the high priority work queue should be the highest priority thread in your system (the default priority is 224). +

+

Compared to the Low Priority Kernel Work Queue. + For less critical, lower priority, application oriented worker thread support, consider enabling the lower priority work queue. The lower priority work queue runs at a lower priority, of course, but has the added advantage that it supports priority inheritance (if CONFIG_PRIORITY_INHERITANCE is also selected): The priority of the lower priority worker thread can then be adjusted to match the highest priority client. +

+

+ Configuration Options. +

+ +

+ Common Configuration Options. + These options apply to all work queues: +

+ + +

4.4.1.2 Low Priority Kernel Work Queue

+

+ Low Priority Kernel Work Queue. + This lower priority work queue is better suited for more extended, application oriented processing such as file system clean-up, memory garbage collection and asynchronous I/O operations. +

+

+ Compared to the High Priority Work Queue. + The lower priority work queue runs at a lower priority than the high priority work queue, of course, and so is inapproperiate to serve as a driver bottom half. The lower priority work queue has the other advantages, however, that make it better suited for some tasks: +

+ +

+ Configuration Options. +

+ + +

4.4.1.3 User-Mode Work Queue

+

+ Work Queue Accessibility. + The high- and low-priority worker threads are kernel-mode threads. In the normal, flat NuttX build, these work queues are are useful to application code and may be shared. However, in the NuttX protected and kernel build modes, kernel mode code is isolated and cannot be accessed from user-mode code. +

+

+ User-Mode Work Queue. + if either CONFIG_BUILD_PROTECTED or CONFIG_BUILD_KERNEL are selected, then the option to enable a special user-mode work queue is enable. The interface to the user-mode work queue is identical to the interface to the kernel-mode work queues and the user-mode work queue is functionally equivalent to the high priority work queue. It differs in that its implementation does not depend on internal, kernel-space facilities. +

+

+ Configuration Options. +

+ + +

4.4.2 Common Work Queue Interfaces

+

4.4.2.1 Work Queue IDs

+ +

+ Work queue IDs. + All work queues use the identical interface functions (at least identical in terms of the function signature). The first parameter passed to the work queue interface function identifies the work queue: +

+

+ Kernel-Mode Work Queue IDs: +

+

+

+ User-Mode Work Queue IDs: +

+

+ +

4.4.2.2 Work Queue Interface Types

+ + + +

4.4.2.3 Work Queue Interfaces

+
4.4.2.3.1 work_queue()
+

+ Function Prototype: +

+

+

+ Description. + Queue work to be performed at a later time. All queued work will be performed on the worker thread of execution (not the caller's). +

+

+ The work structure is allocated by caller, but completely managed by the work queue logic. The caller should never modify the contents of the work queue structure; the caller should not call work_queue() again until either (1) the previous work has been performed and removed from the queue, or (2) work_cancel() has been called to cancel the work and remove it from the work queue. +

+

+ Input Parameters: +

+ +

+ Returned Value: +

+ + +
4.4.2.3.2 work_cancel()
+

+ Function Prototype: +int work_cancel(int qid, FAR struct work_s *work); +

+

+

+ Description. + Cancel previously queued work. This removes work from the work queue. After work has been cancelled, it may be re-queue by calling work_queue() again. +

+

+ Input Parameters: +

+ +

+ Returned Value: +

+ + +
4.4.2.3.3 work_signal()
+

+ Function Prototype: +int work_signal(int qid); +

+

+

+ Description. + Signal the worker thread to process the work queue now. This function is used internally by the work logic but could also be used by the user to force an immediate re-assessment of pending work. +

+

+ Input Parameters: +

+ +

+ Returned Value: +

+ + +
4.4.2.3.4 work_available()
+

+ Function Prototype: +

+

+

+ Description. +

+

+ Input Parameters: + Check if the work structure is available. +

+ +

+ Returned Value: +

+ + +
4.4.2.3.5 work_usrstart()
+

+ Function Prototype: +

+

+

+ Description. + The function is only available as a user interface in the kernel-mode build. In the flat build, there is no user-mode work queue; in the protected mode, the user-mode work queue will automatically be started by the OS start-up code. But in the kernel mode, each user process will be required to start is own, private instance of the user-mode work thread using this interface. +

+

+ Input Parameters: None +

+

+ Returned Value: +

+ + +
4.4.2.3.6 lpwork_boostpriority()
+

+ Function Prototype: +

+

+

+ Description. + Called by the work queue client to assure that the priority of the low-priority worker thread is at least at the requested level, reqprio. This function would normally be called just before calling work_queue(). +

+

+ Input Parameters: +

+ +

+ Returned Value: None +

+ +
4.4.2.3.7 lpwork_restorepriority()
+

+ Function Prototype: +

+

+

+ Description. + This function is called to restore the priority after it was previously boosted. This is often done by client logic on the worker thread when the scheduled work completes. It will check if we need to drop the priority of the worker thread. +

+

+ Input Parameters: +

+ +

+ Returned Value: None +

+ +

4.5 Address Environments

CPUs that support memory management units (MMUs) may provide address environments within which tasks and their child threads execute. The configuration indicates the CPUs ability to support address environments by setting the configuration variable CONFIG_ARCH_HAVE_ADDRENV=y. @@ -2923,35 +3358,35 @@ VxWorks provides the following comparable interface:

@@ -2964,12 +3399,12 @@ VxWorks provides the following comparable interface:

@@ -2992,19 +3427,19 @@ VxWorks provides the following comparable interface:

@@ -3018,17 +3453,17 @@ VxWorks provides the following comparable interface:

-

4.4.1 up_addrenv_create()

+

4.5.1 up_addrenv_create()

Function Prototype:

-

4.4.2 up_addrenv_destroy()

+

4.5.2 up_addrenv_destroy()

Function Prototype:

-

4.4.3 up_addrenv_vtext()

+

4.5.3 up_addrenv_vtext()

Function Prototype:

-

4.4.4 up_addrenv_vdata()

+

4.5.4 up_addrenv_vdata()

Function Prototype:

-

4.4.5 up_addrenv_heapsize()

+

4.5.5 up_addrenv_heapsize()

Function Prototype:

-

4.4.6 up_addrenv_select()

+

4.5.6 up_addrenv_select()

Function Prototype:

-

4.4.7 up_addrenv_restore()

+

4.5.7 up_addrenv_restore()

Function Prototype:

-

4.4.8 up_addrenv_clone()

+

4.5.8 up_addrenv_clone()

Function Prototype:

-

4.4.9 up_addrenv_attach()

+

4.5.9 up_addrenv_attach()

Function Prototype:

-

4.4.10 up_addrenv_detach()

+

4.5.10 up_addrenv_detach()

Function Prototype:

-

4.4.11 up_addrenv_ustackalloc()

+

4.5.11 up_addrenv_ustackalloc()

Function Prototype:

-

4.4.12 up_addrenv_ustackfree()

+

4.5.12 up_addrenv_ustackfree()

Function Prototype:

-

4.4.13 up_addrenv_vustack()

+

4.5.13 up_addrenv_vustack()

Function Prototype:

-

4.4.14 up_addrenv_ustackselect()

+

4.5.14 up_addrenv_ustackselect()

Function Prototype:

-

4.4.15 up_addrenv_kstackalloc()

+

4.5.15 up_addrenv_kstackalloc()

Function Prototype:

-

4.4.16 up_addrenv_kstackfree()

+

4.5.16 up_addrenv_kstackfree()

Function Prototype:

-

4.5 APIs Exported by NuttX to Architecture-Specific Logic

+

4.6 APIs Exported by NuttX to Architecture-Specific Logic

These are standard interfaces that are exported by the OS for use by the architecture specific logic.

-

4.5.1 os_start()

+

4.6.1 os_start()

To be provided

-

4.5.2 OS List Management APIs

+

4.6.2 OS List Management APIs

To be provided

-

4.5.3 sched_process_timer()

+

4.6.3 sched_process_timer()

Function Prototype: void sched_process_timer(void);

Description. @@ -3393,7 +3828,7 @@ VxWorks provides the following comparable interface: MSEC_PER_TICK.

-

4.5.4 sched_timer_expiration()

+

4.6.4 sched_timer_expiration()

Function Prototype:

-

4.5.5 sched_alaram_expiration()

+

4.6.5 sched_alaram_expiration()

Function Prototype:

-

4.5.6 irq_dispatch()

+

4.6.6 irq_dispatch()

Function Prototype: void irq_dispatch(int irq, FAR void *context);

Description. @@ -3448,7 +3883,7 @@ void sched_timer_expiration(void); the appropriate, registered handling logic.

-

4.6 Shared Memory

+

4.7 Shared Memory

Shared memory interfaces are only available with the NuttX kernel build (CONFIG_BUILD_KERNEL=y). These interfaces support user memory regions that can be shared between multiple user processes. @@ -3457,7 +3892,7 @@ void sched_timer_expiration(void); Those interfaces are described below:

-

4.6.1 up_shmat()

+

4.7.1 up_shmat()

Function Prototype:

-

4.6.2 up_shmdt()

+

4.7.2 up_shmdt()

Function Prototype:

-

4.7 On-Demand Paging

+

4.8 On-Demand Paging

The NuttX On-Demand Paging feature permits embedded MCUs with some limited RAM space to execute large programs from some non-random access media. If the platform meets certain requirements, then NuttX can provide on-demand paging: @@ -3521,7 +3956,7 @@ int up_shmdt(uintptr_t vaddr, unsigned int npages); Please see the NuttX Demand Paging design document for further information.

-

4.8 LED Support

+

4.9 LED Support

A board architecture may or may not have LEDs. @@ -3531,7 +3966,7 @@ int up_shmdt(uintptr_t vaddr, unsigned int npages); However, the support provided by each architecture is sufficiently similar that it can be documented here.

-

4.8.1 Header Files

+

4.9.1 Header Files

LED-related definitions are provided in two header files: @@ -3555,7 +3990,7 @@ int up_shmdt(uintptr_t vaddr, unsigned int npages);

-

4.8.2 LED Definitions

+

4.9.2 LED Definitions

The implementation of LED support is very specific to a board architecture. @@ -3619,7 +4054,7 @@ int up_shmdt(uintptr_t vaddr, unsigned int npages); -

4.8.3 Common LED interfaces

+

4.9.3 Common LED interfaces

The <arch-name>/src/common/up_internal.h probably has definitions diff --git a/binfmt/libelf/libelf_load.c b/binfmt/libelf/libelf_load.c index 95d46999aa1..385d3355f74 100644 --- a/binfmt/libelf/libelf_load.c +++ b/binfmt/libelf/libelf_load.c @@ -264,7 +264,10 @@ int elf_load(FAR struct elf_loadinfo_s *loadinfo) elf_elfsize(loadinfo); /* Determine the heapsize to allocate. heapsize is ignored if there is - * no address environment. + * no address environment because the heap is a shared resource in that + * case. If there is no dynamic stack then heapsize must at least as big + * as the fixed stack size since the stack will be allocated from the heap + * in that case. */ #if !defined(CONFIG_ARCH_ADDRENV) diff --git a/binfmt/libnxflat/libnxflat_addrenv.c b/binfmt/libnxflat/libnxflat_addrenv.c index c7e82f53788..371a934048f 100644 --- a/binfmt/libnxflat/libnxflat_addrenv.c +++ b/binfmt/libnxflat/libnxflat_addrenv.c @@ -108,7 +108,10 @@ int nxflat_addrenv_alloc(FAR struct nxflat_loadinfo_s *loadinfo, size_t envsize) } #ifdef CONFIG_ARCH_ADDRENV - /* Determine the heapsize to allocate */ + /* Determine the heapsize to allocate. If there is no dynamic stack then + * heapsize must at least as big as the fixed stack size since the stack + * will be allocated from the heap in that case. + */ #ifdef CONFIG_ARCH_STACK_DYNAMIC heapsize = ARCH_HEAP_SIZE; diff --git a/include/nuttx/wqueue.h b/include/nuttx/wqueue.h index b7c7d96c33d..446e4c89c55 100644 --- a/include/nuttx/wqueue.h +++ b/include/nuttx/wqueue.h @@ -63,10 +63,6 @@ * (which runs at the lowest of priority and may not be appropriate * if memory reclamation is of high priority). If CONFIG_SCHED_HPWORK * is enabled, then the following options can also be used: - * CONFIG_SCHED_HPWORK - Build the high priority work queue. To preserve - * legacy behavior, CONFIG_SCHED_HPWORK is assumed to be true in a flat - * build (CONFIG_SCHED_KERNEL=n) but must be defined in kernel mode - * in order to build the high priority work queue. * CONFIG_SCHED_HPWORKPRIORITY - The execution priority of the high- * priority worker thread. Default: 224 * CONFIG_SCHED_HPWORKPERIOD - How often the worker thread checks for @@ -338,7 +334,7 @@ int work_usrstart(void); * * Description: * Queue work to be performed at a later time. All queued work will be - * performed on the worker thread of of execution (not the caller's). + * performed on the worker thread of execution (not the caller's). * * The work structure is allocated by caller, but completely managed by * the work queue logic. The caller should never modify the contents of @@ -412,6 +408,7 @@ int work_signal(int qid); * Check if the work structure is available. * * Input parameters: + * work - The work queue structure to check. * None * * Returned Value: diff --git a/libc/Kconfig b/libc/Kconfig index d3030ef05dc..8f9569bde0a 100644 --- a/libc/Kconfig +++ b/libc/Kconfig @@ -409,7 +409,7 @@ config LIB_USRWORKPRIORITY int "User mode priority worker thread priority" default 100 ---help--- - The execution priority of the lopwer priority worker thread. Default: 192 + The execution priority of the user-mode priority worker thread. Default: 100 config LIB_USRWORKPERIOD int "User mode worker thread period" @@ -425,7 +425,7 @@ config LIB_USRWORKSTACKSIZE The stack size allocated for the lower priority worker thread. Default: 2K. endif # LIB_USRWORK -endif # BUILD_PROTECTED +endif # BUILD_PROTECTED || BUILD_KERNEL config LIB_KBDCODEC bool "Keyboard CODEC" diff --git a/sched/Kconfig b/sched/Kconfig index a81bfa06d83..791e9194b1b 100644 --- a/sched/Kconfig +++ b/sched/Kconfig @@ -855,7 +855,7 @@ config SCHED_HPWORKPRIORITY The higher priority worker thread is intended to serve as the "bottom" half for device drivers. As a consequence it must run at a very high, fixed priority. Typically, it should be the highest - priority thread in your system. Default: 192 + priority thread in your system. Default: 224 For lower priority, application oriented worker thread support, please consider enabling the lower priority work queue. The lower @@ -903,14 +903,14 @@ config SCHED_LPNTHREADS default 4 if FS_AIO ---help--- This options selects multiple, low-priority threads. This is - essentially a "thread pool" that provides multi-threaded service - of the low-priority work thread. This breaks the serialization + essentially a "thread pool" that provides multi-threaded servicing + of the low-priority work queue. This breaks the serialization of the "queue" (hence, it is no longer a queue at all). This options is required to support, for example, I/O operations that stall waiting for input. If there is only a single thread, then the entire low-priority queue processing stalls in such cases. - Such behvior must be support for asynchronous I/O, AIO (for example). + Such behavior is necessary to support asynchronous I/O, AIO (for example). config SCHED_LPWORKPRIORITY int "Low priority worker thread priority" @@ -959,7 +959,7 @@ config SCHED_LPWORKPRIOMAX it must run at a very high, fixed priority. Typically, it should be the highest priority thread in your system. - This function provides an upper limit on the priority of the lower + This value provides an upper limit on the priority of the lower priority worker thread. This would be necessary, for example, if the higher priority worker thread were to defer work to the lower priority thread. Clearly, in such a case, you would want to limit