Changes between Version 11 and Version 12 of ioc_device_api

Timestamp:

Jan 21, 2020, 8:06:19 PM (5 years ago)

Author:

alain

Comment:

--

ioc_device_api

@@ -5 +5 @@
 == __A) General principles__ ==
 
-This device allows the kernel to access various external mass storage peripherals such as a magnetic hard disk, or a SD card, that can store blocks of data in a linear array of sectors indexed by a simple ''lba'' (logic block address).
+This device allows the kernel to access  external mass storage peripherals such as a magnetic hard disk, or a SD card, that can store blocks of data in a linear array of sectors indexed by a simple ''lba'' (logic block address).
 
 The block size is supposed to be 512 bytes.
@@ -36 +36 @@
 == __C) User API__ ==
 
-The '''void dev_ioc_move_data()''' blocking function moves <count> contiguous blocks of data between the block device,
-indexed by the <lba> argument, and a kernel buffer, identified by the <buffer_xp> argument. 
-* The '''cmd_type''' argument defines the operation type.
-* The '''buffer_xp''' argument is an extended pointer on the kernel buffer.
-* The '''lba''' argument is the first block index in block device.
-* The '''count''' argument is the number of blocks to move.
+* The '''dev_ioc_read( xptr_t buffer_xp , uint32_t lba , uint32_t count )''' blocking function moves <count> contiguous blocks from the block device, starting from block defined by the <lba> argument, to a kernel buffer defined by the <buffer_xp> argument. It register the request in the IOC device waiting queue. Then it blocks and deschedules.
+* The '''dev_ioc_write( xptr_t buffer_xp , uint32_t lba , uint32_t count )''' blocking function moves <count> contiguous blocks from a kernel buffer defined by the <buffer_xp> argument to the block device, starting from block defined by the <lba> argument. It register the request in the IOC device waiting queue. Then it blocks and deschedules.
+* The '''dev_ioc_sync_read( xptr_t buffer_xp , uint32_t lba , uint32_t count )''' blocking function moves <count> contiguous blocks from the block device, starting from block defined by the <lba> argument, to a kernel buffer defined by the <buffer_xp> argument. It calls directly the IOC driver without rescheduling, and without using the IOC device waiting queue and the server thread.
+* The '''dev_ioc_sync_write( xptr_t buffer_xp , uint32_t lba , uint32_t count )''' blocking function moves <count> contiguous blocks from a kernel buffer defined by the <buffer_xp> argument to the block device, starting from block defined by the <lba> argument. It calls directly the IOC driver without rescheduling, and without using the IOC device waiting queue and the server thread.
 
 The I/O operation is always blocking for the calling thread, but the blocking policy depends on the operation type.
@@ -50 +48 @@
  1. When a client thread request an I/O operation, the request is registered in the ''ioc_command_t'' structure embedded in the client thread descriptor, and the client thread registers itself in the waiting queue rooted in the IOC chdev. Then the client thread blocks on the THREAD_BLOCKED_IO condition, and deschedules.
  1. The DEV server thread attached to the IOC device descriptor handles all commands registered in the IOC device waiting queue. For each pending request, it calls the IOC driver CMD (command) function to ask the hardware device to do the transfer. Then, the server thread blocks on the THREAD_BLOCKED_ISR condition, and deschedules.  
- 1. When the I/O operation completed, the IOC driver ISR (Interrupt Service Routine) signaling completion reactivates the server thread.
- 1. The server thread reactivates the client thread, and handle the next request in the IOC waiting queue, or reschedules if the queue is empty.
+ 1. When the I/O operation completed, the IOC driver reactivates the server thread.
+ 1. The server thread reactivates the client thread, and handle the next request in the IOC waiting queue, or deschedules if the queue is empty.
 
 Note : According to the scheduler policy, the DEV thread has an higher priority than any user thread, but it is not selected when the associated waiting queue is empty.