Changes between Version 15 and Version 16 of ioc_device_api
- Timestamp:
- Jan 21, 2020, 11:50:56 PM (5 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
ioc_device_api
v15 v16 9 9 The block size is supposed to be 512 bytes. 10 10 11 The ''user''API contains the functions used by the user-level system calls, and defines four operation types : the '''IOC_READ''', '''IOC_WRITE''', '''IOC_SYNC_READ''', and '''IOC_SYNC_WRITE''' operations move a given number of contiguous blocks between the block device and a kernel memory buffer. This API is detailed in section C below.11 The "user" API contains the functions used by the user-level system calls, and defines four operation types : the '''IOC_READ''', '''IOC_WRITE''', '''IOC_SYNC_READ''', and '''IOC_SYNC_WRITE''' operations move a given number of contiguous blocks between the block device and a kernel memory buffer. This API is detailed in section C below. 12 12 13 13 * The '''asynchronous''' READ and WRITE operations are not directly executed by the client thread. The READ and WRITE requests are registered in the waiting queue rooted in the IOC chdev descriptor. These requests are actually handled by a dedicated server thread running in the cluster containing the chdev descriptor, that calls the ''ioc_driver_cmd()'' function. … … 19 19 An exception is the IOC-RDK implementation, where the block device is actually implemented as physical memory. This IOC-RDK implementation does not use DMA, and does not use an IRQ. The data transfer is directly executed by the ''ioc_driver_cmd()'' software function. 20 20 21 To access the various drivers, the IOC device defines a lower-level ''driver''API, that is detailed in section D below.21 To access the various drivers, the IOC device defines a lower-level "driver" API, that is detailed in section D below. 22 22 23 23 All IOC device structures and access functions are defined in the [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/kernel/devices/dev_ioc.c dev_ioc.c] et [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/kernel/devices/dev_ioc.h dev_ioc.h] files. … … 33 33 It must be called by a local thread. 34 34 35 == __C) UserAPI__ ==35 == __C) The "user" API__ == 36 36 37 These four I/O operations are blocking for the calling thread, but the blocking policy depends on the operation type.37 These four I/O operations are blocking and return only when the transfer is completed, but the blocking policy depends on the operation type. 38 38 39 39 === C.1) Asynchronous operations === … … 60 60 These synchronous operations use neither the IOC device waiting queue, nor the DEV server thread. The client thread does not deschedules : it registers the arguments in the IOC command structure embedded in the client thread descriptor, and calls directly the blocking ''ioc_driver_cmd()'' function, that executes the command and returns only when the transfer is completed. For a synchronous request, and even if the the hardware IOC controller has a DMA capability, the ioc_driver_cmd() function is supposed to use a polling strategy to wait the transfer completion, withoutdriver 61 61 62 == __D) DriverAPI__ ==62 == __D) The "driver" API__ == 63 63 64 64 All IOC drivers must define three functions : 65 * void '''ioc_driver_init( chdev_t *ioc_chdev ) 66 * void '''ioc_driver_cmd '''( xptr_t thread_xp )67 * void '''ioc_driver_isr '''( chdev_t * ioc_chdev )65 * void '''ioc_driver_init( chdev_t *ioc_chdev )''' 66 * void '''ioc_driver_cmd( xptr_t thread_xp )''' 67 * void '''ioc_driver_isr( chdev_t * ioc_chdev )''' 68 68 69 69 The ''ioc_driver_cmd()'' function arguments are actually defined in the ''ioc_command_t'' structure embedded in the client thread descriptor. One command contains four informations:
