Changes between Version 12 and Version 13 of io_operations


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

--

Legend:

Unmodified
Added
Removed
Modified
  • io_operations

    v12 v13  
    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) Generic Devices  API  ==
     21== B) Generic Devices  APIs  ==
    2222
    23 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.
     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, and the physical base address of the segment containing the addressable registers for this peripheral channel.
    2424
    25 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.
     25Each device descriptor contains a waiting queue of pending commands registered by the various clients threads.
    2626
    2727For 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.
     
    3636== C) Waiting queue Management ==
    3737
    38 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.
     38The 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.
    3939
    40 The waiting queue is handled as a Multi-Writers / Single-Reader FIFO. The N writers are the clients threads, whose number is not bounded.
    41 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.
     40For 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.
     41
     42The 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.
     43The 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.
    4244
    4345Finally, 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.
    4446
    45 * 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.
    46 * 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.
     47* 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.
     48* 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.
    4749
    4850== D) Drivers API ==