Changes between Version 52 and Version 53 of io_operations


Ignore:
Timestamp:
Dec 7, 2019, 11:57:20 PM (3 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • io_operations

    v52 v53  
    5858
    5959The 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.
    60 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 is descheduled. It is activated by the client thread when a new command is registered in the queue.
     60The single reader is the 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 is descheduled. It is activated by the client thread when a new command is registered in the queue.
    6161
    6262Finally, each generic device descriptor contains a link to the specific driver associated to the available hardware implementation. This link is established in the kernel initialization phase.
     
    6464== E) Drivers API ==
    6565
    66 To 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.
    67 
    68 To 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.
     66To 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 architecture.
     67To signal the completion of a given I/O operation, the peripheral rises an IRQ to execute a specific ISR (Interrupt Service Routine).
    6968
    7069Any driver must therefore implement the three following functions:
     
    9089== F) Global I/O operation scenario  ==
    9190
    92 The I/O operation mechanism involves generally three clusters : client cluster / server cluster / IO cluster. It does not use any RPC, but uses only remote accesses to to execute the three steps implied by any I/O operation:
     91The I/O operation mechanism involves generally three clusters : client cluster / server cluster / IO cluster. It does not use any RPC, but uses only remote accesses to execute the three steps implied by any I/O operation:
    9392 * To post a new command in the waiting queue of a given (remote) device descriptor, the client thread uses only few remote accesses to be registered in the distributed XLIST rooted in the server cluster.
    9493 * To launch the I/O operation on the (remote) peripheral, the server thread uses only remote accesses to the physical registers located in the I/O cluster.
    95  * To complete the I/O operation, the ISR running on the client cluster accesses peripheral registers in the I/O cluster, reports the I/O operation status in the command descriptor, and unblocks the client and server threads, using only local or remote accesses.
     94 * To complete the I/O operation, the ISR running on the client cluster accesses peripheral registers in the I/O cluster, reports the I/O operation status in the command descriptor, and unblocks the client and server threads, using remote accesses if required.
    9695
    9796== G) Interrupts Routing ==
    9897
    99 The completion of an I/O operation is signaled by the involved hardware device using an interrupt. In ALMOS-MKH,  this interrupt is handled by the core running the server thread that launched the I/O operation. Therefore, the interrupt must be routed to the cluster containing the device descriptor involved in the I/O operation.
     98The completion of an I/O operation is signaled by the involved peripheral using an interrupt. In ALMOS-MKH,  this interrupt is handled by the core running the server thread that launched the I/O operation. Therefore, the interrupt must be routed to the cluster containing the ''chdev'' involved in the I/O operation.
    10099
    101 ALMOS-MKH makes the assumption that interrupt routing (from peripherals to cores) is done by a dedicated hardware device, called '''PIC''' (Programmable Interrupt Controller). This hardware device also helps the the kernel interrupt handler, running on the selected core, to select the relevant ISR (Interrupt Service Routine) to be executed.
     100ALMOS-MKH makes the assumption that interrupt routing (from peripherals to cores) is done by a dedicated device, called '''PIC''' (Programmable Interrupt Controller). This device also helps the the kernel interrupt handler, running on the selected core, to select the relevant ISR (Interrupt Service Routine) to be executed.
    102101
    103102This generic PIC device is supposed to be implemented as a ''distributed'' hardware infrastructure containing two types of hardware components:
     
    138137== H) Text Terminals ==
    139138
    140 The target hardware architectures generally provide a variable - but bounded - number of text terminals (called TXT channels in ALMOS-MKH). The  actual number of terminals (NB_TXT_CHANNELS) is defined in the ''arch_info.bin'' file. We describe here how ALMOS-MKH uses these terminals:
     139The hardware architecture generally provide a variable - but bounded - number of text terminals (called TXT channels in ALMOS-MKH). The  actual number of terminals (NB_TXT_CHANNELS) is defined in the ''arch_info.bin'' file. We describe here how ALMOS-MKH uses these terminals:
    141140
    142141'''1)''' The TXT[0] terminal is reserved for the kernel. It is normally used by the kernel to display log and/or debug messages. It can also be used by user processes for debug, through the specific display_xxx() system calls, that should not be used in normal exploitation.
    143142
    144 '''2)''' The other (NB_TXT_CHANNELS - 1) terminals TXT[i] are shared resources used by user processes. During kernel initialization,  ALMOS-MKH creates the first INIT user process, that creates itself (NB_TXT_CHANNELS -1) KSH user processes (one shell per user text terminal). All processes created by a KSH[i] process share the same TXT[i] terminal as the parent process, and belong to the same group of process.
     143'''2)''' The other (NB_TXT_CHANNELS - 1) terminals TXT[i] are used by user processes. The first INIT user process,  creates (NB_TXT_CHANNELS -1) KSH user processes (one shell per user text terminal). All processes created by a KSH[i] process share the same TXT[i] terminal as the parent process, and belong to the same group of process.
    145144
    146 '''3)''' In the present implementation, the INIT process and the the KSH[i] processes are never deleted : they do not call the exit() scale, and cannot be killed.
     145'''3)''' In the present implementation, the INIT process and the the KSH[i] processes are never deleted : they do not call the exit() syscall, and cannot be killed.
    147146
    148147'''4)''' Regarding the WRITE accesses, all processes attached to the same TXT_TX[i] terminal can atomically display character strings. There is no guaranty on the order, when these strings are issued by different processes, because these strings are simply sequentialized by the kernel thread associated to the shared TXT_TX[i] device.
     
    171170===  2. X86_64 architecture ===
    172171
    173  
     172TODO