[RTEMS Project] #5000: Implement POSIX Asynchronous IO

[RTEMS trac]

#5000: Implement POSIX Asynchronous IO
---------------------------+---------------------
 Reporter:  Joel Sherrill  |       Owner:  (none)
     Type:  enhancement    |      Status:  new
 Priority:  normal         |   Milestone:
Component:  posix          |     Version:
 Severity:  normal         |  Resolution:
 Keywords:  SoC, POSIX     |  Blocked By:
 Blocking:                 |
---------------------------+---------------------

Old description:

> RTEMS does not currently support POSIX Asynchronous IO as defined by The
> Open Group. These methods and associated constants are prototyped by the
> [​http://www.opengroup.org/onlinepubs/009695399/basedefs/aio.h.html
> <aio.h>] header file which is cpukit/posix/include/aio.h in the RTEMS
> source tree. The following methods have already been implemented but
> should be reviewed against the POSIX specification to ensure they are as
> complete as possible:
>
> - ​aio_read()
> ​- aio_write()
> ​- aio_cancel()
> ​- aio_error()
> ​- aio_return()
>
> The implementation of the above AIO methods includes a server thread
> which performs the user's AIO requests. These AIO methods request a
> SINGLE operation.
>
> The method ​lio_listio() is not implemented currently in RTEMS. The
> current implementation between the aio_ methods and the server thread
> will need to grow to support a list. The straightforward way to
> accomplish this is to modify the current aio_ infrastructure to treat a
> single aio_ request as a list of one. Then the lio_listio() should be a
> simple modification.
>
> The current implementation leans to a long-ish function to process AIO
> requests. This processing should be refactored so while iterating the
> list, the server thread calls a helper method for each request type.
>
> The implementation has a single server thread. The server thread
> characteristics such as stack size and priority should be application
> configurable.
>
> There will need to be tests added for the new functionality. Coverage
> will need to be reviewed for the AIO functionality.
>
> Possible Mentors: Joel Sherrill, Gedare Bloom, Chris Johns, Kinsey Moore

New description:

 RTEMS does not currently support POSIX Asynchronous IO as defined by The
 Open Group. These methods and associated constants are prototyped by the
 [​http://www.opengroup.org/onlinepubs/009695399/basedefs/aio.h.html
 <aio.h>] header file which is cpukit/posix/include/aio.h in the RTEMS
 source tree. The following methods have already been implemented but
 should be reviewed against the POSIX specification to ensure they are as
 complete as possible:

 - ​aio_read()
 ​- aio_write()
 ​- aio_cancel()
 ​- aio_error()
 ​- aio_return()

 The implementation of the above AIO methods includes a server thread which
 performs the user's AIO requests. These AIO methods request a SINGLE
 operation.

 The method ​lio_listio() is not implemented currently in RTEMS. The
 current implementation between the aio_ methods and the server thread will
 need to grow to support a list. The straightforward way to accomplish this
 is to modify the current aio_ infrastructure to treat a single aio_
 request as a list of one. Then the lio_listio() should be a simple
 modification.

 The current implementation leans to a long-ish function to process AIO
 requests. This processing should be refactored so while iterating the
 list, the server thread calls a helper method for each request type.

 The implementation has a single server thread. The server thread
 characteristics such as stack size and priority should be application
 configurable.

 There will need to be tests added for the new functionality. Coverage will
 need to be reviewed for the AIO functionality.

 Possible Mentors: Joel Sherrill, Gedare Bloom, Chris Johns, Kinsey Moore

--

Comment (by Joel Sherrill):

 My thoughts on an implementation plan. The functionality of lio_listio()
 can be implemented by a series of incremental changes. Much of the
 functionality is already present in the existing aio_* methods. Some of
 these can happen in parallel. Ensure all AIO tests pass as modifications
 are made and new tests are added as needed.

 * Review existing AIO functions to gain understanding of the
 implementation and to check each POSIX function against the specification.
 If there is any missing functionality, this plan will have to be adjusted
 to account for that.

 * Refactor AIO processing so a helper method exists for processing
 existing AIO operations. Eventually these will be called for each
 requested operation in a list. Refactoring helper methods will make the
 server thread easier to read. Change no functionality in this step.
   - This is likely a good spot to submit a patch.

 * Modify the message structure between the aio_ functions and the server
 to include a number of messages. It is one for all aio_ operations and a
 user provided count for lio_listio. Included in this is modifying the
 server to process a list of requests.
   - This is likely a good spot to submit a patch.

 * Implement lio_listio(). Messages to the server and it processing a list
 should already be implemented from the refactoring and adding a list
 length.

 * Add generation of a signal at list completion. Verify this is or is not
 a requirement for aio_ functions.

 * Ensure the implementation has good test coverage.

--
Ticket URL: <http://devel.rtems.org/ticket/5000#comment:1>
RTEMS Project <http://www.rtems.org/>
RTEMS Project