nuttx/nuttx-update
1
2
Fork 1
Code Issues 1 Pull requests 1 Projects Releases Packages Wiki Activity Actions

Update some comments

Browse source
This commit is contained in:
Gregory Nutt 2014-10-07 08:34:10 -06:00
parent a0f3267d5c
commit 4c7b988525
3 changed files with 13 additions and 53 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

32
fs/aio/aio_read.c
View file

@ -158,6 +158,12 @@ static void aio_read_worker(FAR void *arg)
* has been initiated or queued to the file or device (even when the data
* cannot be delivered immediately).
*
* If prioritized I/O is supported for this file, then the asynchronous
* operation will be submitted at a priority equal to a base scheduling
* priority minus aiocbp->aio_reqprio. If Thread Execution Scheduling is
* not supported, then the base scheduling priority is that of the calling
* thread (the latter is implemented at present).
*
* The aiocbp value may be used as an argument to aio_error() and
* aio_return() in order to determine the error status and return status,
* respectively, of the asynchronous operation while it is proceeding. If
@ -233,32 +239,6 @@ static void aio_read_worker(FAR void *arg)
* description associated with aiocbp->aio_fildes.
*
* POSIX Compliance:
* - The POSIX specification of asynchronous I/O implies that a thread is
* created for each I/O operation. The standard requires that if
* prioritized I/O is supported for this file, then the asynchronous
* operation will be submitted at a priority equal to a base scheduling
* priority minus aiocbp->aio_reqprio. If Thread Execution Scheduling is
* not supported, then the base scheduling priority is that of the calling
* thread.
*
* My initial gut feeling is the creating a new thread on each asynchronous
* I/O operation would not be a good use of resources in a deeply embedded
* system. So I decided to execute all asynchronous I/O on a low-priority
* or user-space worker thread. There are two negative consequences of this
* decision that need to be revisited:
*
* 1) The worker thread runs at a fixed priority making it impossible to
* meet the POSIX requirement for asynchronous I/O. That standard
* specifically requires varying priority.
* 2) On the worker thread, each I/O will still be performed synchronously,
* one at a time. This is not a violation of the POSIX requirement,
* but one would think there could be opportunities for concurrent I/O.
*
* In reality, in a small embedded system, there will probably only be one
* real file system and, in this case, the I/O will be performed sequentially
* anyway. Most simple embedded hardware will not support any concurrent
* accesses.
*
* - Most errors required in the standard are not detected at this point.
* There are no pre-queuing checks for the validity of the operation.
*

32
fs/aio/aio_write.c
View file

@ -203,6 +203,12 @@ static void aio_write_worker(FAR void *arg)
* has been initiated or queued to the file or device (even when the data
* cannot be delivered immediately).
*
* If prioritized I/O is supported for this file, then the asynchronous
* operation will be submitted at a priority equal to a base scheduling
* priority minus aiocbp->aio_reqprio. If Thread Execution Scheduling is
* not supported, then the base scheduling priority is that of the calling
* thread (the latter is implemented at present).
*
* The aiocbp value may be used as an argument to aio_error() and
* aio_return() in order to determine the error status and return status,
* respectively, of the asynchronous operation while it is proceeding.
@ -280,32 +286,6 @@ static void aio_write_worker(FAR void *arg)
* with aiocbp->aio_fildes.
*
* POSIX Compliance:
* - The POSIX specification of asynchronous I/O implies that a thread is
* created for each I/O operation. The standard requires that if
* prioritized I/O is supported for this file, then the asynchronous
* operation will be submitted at a priority equal to a base scheduling
* priority minus aiocbp->aio_reqprio. If Thread Execution Scheduling is
* not supported, then the base scheduling priority is that of the calling
* thread.
*
* My initial gut feeling is the creating a new thread on each asynchronous
* I/O operation would not be a good use of resources in a deeply embedded
* system. So I decided to execute all asynchronous I/O on a low-priority
* or user-space worker thread. There are two negative consequences of this
* decision that need to be revisited:
*
* 1) The worker thread runs at a fixed priority making it impossible to
* meet the POSIX requirement for asynchronous I/O. That standard
* specifically requires varying priority.
* 2) On the worker thread, each I/O will still be performed synchronously,
* one at a time. This is not a violation of the POSIX requirement,
* but one would think there could be opportunities for concurrent I/O.
*
* In reality, in a small embedded system, there will probably only be one
* real file system and, in this case, the I/O will be performed sequentially
* anyway. Most simple embedded hardware will not support any concurrent
* accesses.
*
* - Most errors required in the standard are not detected at this point.
* There are no pre-queuing checks for the validity of the operation.
*

2
include/aio.h
View file

@ -126,7 +126,7 @@ struct aiocb
off_t aio_offset; /* File offset */
size_t aio_nbytes; /* Length of transfer */
int aio_fildes; /* File descriptor */
int8_t aio_reqprio; /* Request priority offset */
int8_t aio_reqprio; /* Request priority offset (not used) */
uint8_t aio_lio_opcode; /* Operation to be performed */
/* Non-standard, implementation-dependent data. For portability reasons,