Changes between Version 52 and Version 53 of io_operations
- Timestamp:
- Dec 7, 2019, 11:57:20 PM (4 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
io_operations
v52 v53 58 58 59 59 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. 60 The single reader is aserver 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.60 The 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. 61 61 62 62 Finally, 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. … … 64 64 == E) Drivers API == 65 65 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. 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 architecture. 67 To signal the completion of a given I/O operation, the peripheral rises an IRQ to execute a specific ISR (Interrupt Service Routine). 69 68 70 69 Any driver must therefore implement the three following functions: … … 90 89 == F) Global I/O operation scenario == 91 90 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 toexecute the three steps implied by any I/O operation:91 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 execute the three steps implied by any I/O operation: 93 92 * 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. 94 93 * 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. 96 95 97 96 == G) Interrupts Routing == 98 97 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 descriptorinvolved in the I/O operation.98 The 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. 100 99 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 hardwaredevice also helps the the kernel interrupt handler, running on the selected core, to select the relevant ISR (Interrupt Service Routine) to be executed.100 ALMOS-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. 102 101 103 102 This generic PIC device is supposed to be implemented as a ''distributed'' hardware infrastructure containing two types of hardware components: … … 138 137 == H) Text Terminals == 139 138 140 The target hardware architecturesgenerally 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:139 The 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: 141 140 142 141 '''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. 143 142 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. 145 144 146 '''3)''' In the present implementation, the INIT process and the the KSH[i] processes are never deleted : they do not call the exit() s cale, 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. 147 146 148 147 '''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. … … 171 170 === 2. X86_64 architecture === 172 171 173 172 TODO