Changes between Version 12 and Version 13 of io_operations

Timestamp:

Nov 3, 2016, 1:42:37 PM (8 years ago)

Author:

alain

Comment:

--

io_operations

@@ -19 +19 @@
 The set of available peripherals, and their localisation in a given many-core architecture must be described in the '''arch_info;py''' file. For each peripheral, the composite index is implemented as a 32 bits integer, where the 16 MSB bits define the type, and the 16 LSB bits define the subtype.
 
-== B) Generic Devices  API  ==
+== B) Generic Devices  APIs  ==
 
-To represent the available peripherals in a given manicore architecture, ALMOS-MK uses generic ''device descriptors'', implemented by the '''device_t''' structure. For multi-channels peripherals, ALMOS-MK defines one ''device descriptor'' per channel.  this descriptor contains the functional index, the implementation index, the channel index, the physical base address of the segment containing the addressable registers for this peripheral channel. 
+To represent the available peripherals in a given manicore architecture, ALMOS-MK uses generic ''device descriptors'' (implemented by the ''device_t'' structure). For multi-channels peripherals, ALMOS-MK defines one ''device descriptor'' per channel.  this descriptor contains the functional index, the implementation index, the channel index, and the physical base address of the segment containing the addressable registers for this peripheral channel. 
 
-Each device descriptor contains a waiting queue of pending commands registered by the various clients threads. This waiting queue is implemented as a distributed XLIST, rooted in the device descriptor. Any thread, running in any cluster can register a command in this queue.
+Each device descriptor contains a waiting queue of pending commands registered by the various clients threads. 
 
 For each generic device type, the device specific API defines the list of available commands, and the specific structure defining the command descriptor (containing the command type and arguments). This structure is embedded (as an union of the various device types) in the thread descriptor, to be passed to the hardware specific driver. 
@@ -36 +36 @@
 == C) Waiting queue Management ==
 
-For all I/O operations, ALMOS-MK implements a blocking policy: The thread calling a command function to launch an I/O operation is blocked on the THREAD_BLOCKED_IO condition, and deschedule. It will be re-activated by the driver ISR (Interrupt Service Routine) signaling the completion of the I/O operation.
+The commands waiting queue is implemented as a distributed XLIST, rooted in the device descriptor. To launch an I/O operation,  any thread, running in any cluster, call a function of the device API. This function builds the command descriptor, registers the command in the thread descriptor, and registers the thread in the waiting queue. 
 
-The waiting queue is handled as a Multi-Writers / Single-Reader FIFO. The N writers are the clients threads, whose number is not bounded.
-The single reader is the server thread associated to the device descriptor. This thread is in charge of consuming the pending commands from the waiting queue. When the queue is empty, the server thread blocks on the THREAD_BLOCKED_QUEUE condition, and deschedule. It is re-activated by the client thread when a new command is registered in the queue.
+For all I/O operations, ALMOS-MK implements a blocking policy: The thread calling a command function is blocked on the THREAD_BLOCKED_IO condition, and deschedule. It will be re-activated by the driver ISR (Interrupt Service Routine) signaling the completion of the I/O operation.
+
+The waiting queue is handled as a Multi-Writers / Single-Reader FIFO, protected by a remote_lock. The N writers are the clients threads, whose number is not bounded.
+The single reader is a server thread associated to the device descriptor, and created at kernel initialization. This thread is in charge of consuming the pending commands from the waiting queue. When the queue is empty, the server thread blocks on the THREAD_BLOCKED_QUEUE condition, and deschedule. It is re-activated by the client thread when a new command is registered in the queue.
 
 Finally, each device descriptor for a generic device XYZ contains a link to the specific driver associated to the available hardware implementation. This link is established in the kernel initialization phase.
 
-* As '''internal peripheral''' are private resources, replicated in all clusters, the device descriptor is stored in the same cluster as the hardware device itself. Therefore, all accesses are local.
-* For '''external peripherals''', the hardware devices are shared resources located in the I/O cluster. To minimize contention, the device descriptors are distributed on all clusters, as uniformly as possible. Therefore, an I/O operation involve generally three clusters: the client cluster, the I/O cluster, and the cluster containing the device descriptor.
+* As '''internal peripheral''' are private resources, replicated in all clusters, the device descriptor is stored in the same cluster as the hardware device itself. Therefore, most accesses are local.
+* For '''external peripherals''', the hardware devices are shared resources, located in the I/O cluster. To minimize contention, the device descriptors are distributed on all clusters, as uniformly as possible. Therefore, an I/O operation involve generally three clusters: the client cluster, the I/O cluster, and the server cluster, containing the device descriptor.
 
 == D) Drivers API ==