Changes between Version 9 and Version 10 of io_operations


Ignore:
Timestamp:
Nov 3, 2016, 1:03:53 PM (8 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • io_operations

    v9 v10  
    1919The 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.
    2020
    21 == B) Device Descriptors Placement ==
     21== B) Device  API ==
    2222
    23 To represent the available peripherals in a given manicore architecture, ALMOS-MK uses device descriptors, implemented as the '''device_t''' structure. A device descriptor describes a single channel of a peripheral. It contains the functional index, the implementation index, the channel index, the physical base address, and the size of the physical segment containing the addressable registers for this peripheral channel.
     23To 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.
    2424
    25 Each device descriptor contains also an embedded waiting queue containing the pending requests registered by the various clients. A client can be any thread, running on any core, in any cluster of the manicure architecture.
     25Each 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.
     26
     27For 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.
     28
     29The set of supported generic devices, and the associated APIs are defined below:
     30
     31|| type ||  usage                          ||
     32|| IOC  || Block device controller ||
     33|| TXT  || text terminal controller ||
     34|| NIC  || network interface controller ||  ||
     35For all I/O operations, ALMOS-MK implements a blocking policy: The thread calling a command function to launch an I/O operation on device XYZ 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 he I/O operation.
     36
     37The waiting queue is handled as a Multi-Writers / Single-Reader FIFO. The N writers are the clients threads, whose number is not bounded.
     38The 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.
    2639
    2740Finally, 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.
    … …  
    3043* 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.
    3144
    32  
     45== C) Driver API ==
     46
     47To start an I/O operation the server thread associated to the device must call the specific driver corresponding to the hardware peripheral available in the manycore architecture.
     48
     49To signal the completion of a given I/O operation, the peripheral rises an IRQ to execute a specific ISR (Interrupt Service Routine) in the client cluster, on the core running the client thread. This requires to dynamically route the IRQ to this core.
     50
     51Any driver must therefore implement the three following functions:
     52
     53=== '''driver_init()''' ===
     54 This functions initialises both the peripheral hardware registers, and the specific global variables defined by a given hardware implementation. It is called in the kernel initialization phase.
     55
     56=== '''driver_cmd( xptr_t  thread , device_t * device ) ===
     57This function  is called by the server thread. It access to the peripheral hardware registers to start the I/O operation. Depending on the hardware peripheral implementation, can be blocking or non-blocking for the server thread.
     58 * It is blocking on the THREAD_BLOCKED_DEV_ISR condition, if the hardware peripheral supports only one simultaneous I/O operation. Examples are a simple disk controller, or a text terminal controller. The blocked server thread must be re-activated by the ISR signaling completion of the current I/O operation.
     59 * It is non-blocking if the hardware peripheral supports several simultaneous I/O operations. Example is an AHCI compliant disk controller. It blocks only if the number of simultaneous I/O operations becomes is larger than the max number supported by the hardware.
     60The ''thread'' argument is the extended pointer on the client thread, containing the embedded command descriptor. The ''device'' argument
     61is the local pointer on the device descriptor.
     62
     63=== '''diver_isr( xptr_t device )''' ===
     64This function is executed in the client cluster, on the core running the client thread.  It access the peripheral hardware register to get the I/O operation error status, acknowledge the IRQ, and unblock the client thread.
     65If the server thread has been blocked, it unblock also the server thread.
     66The ''device'' argument is the extended pointer on the device descriptor.
     67
     68== D) Implementation ==
     69
     70It is worth to note that this  general I/O operation mechanism involve generally three clusters (client cluster / server cluster / IO cluster), but does not use any RPC:
     71 * to post a new command in the waiting queue of a given (remote) device descriptor, the client thread uses only few remote access to be registered in the distributed XLIST rooted in the server cluster.
     72 * to launch the I/O operation on the (remote) peripheral, the server thread uses only remote access access the physical registers located in the I/O cluster.
     73 * To complete the I/O operation, the ISR running on the client cluster access peripheral registers in I/O clusters, reports I/O operation status in the command descriptor, and unblock client and server thread using only remote accesses.
     74