Changes between Version 10 and Version 11 of io_operations


Ignore:
Timestamp:
Nov 3, 2016, 1:25:09 PM (7 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • io_operations

    v10 v11  
    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  API  ==
     21== B) Generic Devices  API  ==
    2222
    2323To 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.
    … …  
    2929The set of supported generic devices, and the associated APIs are defined below:
    3030
    31 || type ||  usage                          ||
    32 || IOC  || Block device controller ||
    33 || TXT  || text terminal controller ||
    34 || NIC  || network interface controller ||  ||
    35 For 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.
     31|| device || type ||  usage                                 || api definition                         ||
     32|| IOC     || ext   || block device controller        || [wiki: ioc_device_api ioc_api] ||
     33|| TXT     || ext   || text terminal controller        || [wiki: txt_device_api txt_api] ||
     34|| NIC     || ext   || network interface controller || [wiki: nic_device_api nic_api] ||
     35
     36== C) Waiting queue Management ==
     37
     38For 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.
    3639
    3740The waiting queue is handled as a Multi-Writers / Single-Reader FIFO. The N writers are the clients threads, whose number is not bounded.
    … …  
    4346* 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.
    4447
    45 == C) Driver API ==
     48== D) Drivers API ==
    4649
    4750To 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.
    … …  
    5154Any driver must therefore implement the three following functions:
    5255
    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.
     56'''driver_init()'''
    5557
    56 === '''driver_cmd( xptr_t  thread , device_t * device ) ===
     58This 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.
     59
     60'''driver_cmd( xptr_t  thread , device_t * device )
     61
    5762This 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.
    5863 * 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.
    … …  
    6166is the local pointer on the device descriptor.
    6267
    63 === '''diver_isr( xptr_t device )''' ===
     68'''diver_isr( xptr_t device )'''
     69
    6470This 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.
    6571If the server thread has been blocked, it unblock also the server thread.
    6672The ''device'' argument is the extended pointer on the device descriptor.
    6773
    68 == D) Implementation ==
     74== E) Implementation ==
    6975
    7076It 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:
    … …  
    7278 * 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.
    7379 * 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