Changes between Version 55 and Version 56 of io_operations

Timestamp:

Jan 20, 2020, 12:35:55 PM (5 years ago)

Author:

alain

Comment:

--

io_operations

@@ -21 +21 @@
 == B) Generic Devices  APIs  ==
 
-To represent the available peripherals in a given manycore architecture, ALMOS-MKH uses device descriptors  (implemented by the ''chdev_t'' structure). For multi-channels peripherals, ALMOS-MKH defines one ''chdev'' 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. It contains also the root of a waiting queue of pending commands registered by the various client threads. 
+To represent the peripherals, ALMOS-MKH uses device descriptors  (implemented by the ''chdev_t'' structure). For multi-channels peripherals, ALMOS-MKH defines one ''chdev'' 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. It contains also the root of a waiting queue of pending commands registered by the various client threads. 
 
 The generic ''chdev'' API is defined in the [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/kernel/kern/chdev.h  almos-mkh/kernel/kern/chdev.h] and [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/kernel/kern/chdev.c  almos-mkh/kernel/kern/chdev.c] files.
 
-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). As an IO operation is blocking for the calling thread, a client thread can only post one command at a given time. This command is registered in the client thread descriptor, to be passed to the hardware specific driver. 
+For each functional 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). As an IO operation is blocking for the calling thread, a client thread can only post one command at a given time. This command is registered in the client thread descriptor, to be passed to the hardware specific driver. 
 
 The set of supported generic devices, and their associated APIs are defined below:
@@ -33 +33 @@
 ||   TXT                   || Text Terminal controller                 || [wiki:txt_device_api txt_api] ||
 ||   NIC                   || Network interface controller          || [wiki:nic_device_api nic_api] ||
+||   FBF                   || Frame Buffer controller                 || [wiki:fbf_device_api nic_api] ||
 ||   PIC                   || Programmable Interrupt controller || [wiki:pic_device_api pic_api] ||
 
@@ -53 +54 @@
 == D) Waiting queue Management ==
 
-The commands waiting queue is implemented as a distributed XLIST, rooted in the device descriptor. To launch an I/O operation,  a client thread, running in any cluster, calls a function of the device API. This function builds the command descriptor embedded in the thread descriptor, and registers the thread in the waiting queue. 
+The commands waiting queue is implemented as a distributed XLIST, rooted in the device descriptor. To launch an I/O operation,  a client thread, running in any cluster, calls a function of the device API. This function registers the command in the thread descriptor, and registers the thread in the waiting 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 descheduled. It will be re-activated by the driver ISR (Interrupt Service Routine) signaling the completion of the I/O operation.
+For most I/O operations, ALMOS-MK implements a blocking policy: the thread calling a command function is blocked on the THREAD_BLOCKED_IO condition, and descheduled. 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.