Changes between Version 125 and Version 126 of library_stdio


Ignore:
Timestamp:
Oct 3, 2015, 12:58:42 PM (9 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • library_stdio

    v125 v126  
    7171
    7272 === 5) void '''giet_pthread_yield'''() ===
    73 The thread calling this function is descheduled and the processor is allocated to another thread. The calling thread is not deactivated and keep in the ''runable'' state.
     73The thread calling this function is descheduled and the processor is allocated to another thread. The calling thread is not deactivated and stay in the ''runable'' state.
    7474
    7575The following functions define various GIET_VM specific extensions to the POSIX threads API.
    … …  
    9494 == __Application related system calls__ ==
    9595
    96  === 1) void '''giet_kill_application'''( char* name ) ===
    97 This function kill the application identified by the vspace '''name''' argument:
    98 All application threads defined in the mapping receive a KILL signal and will be deactivated at the next context switch. The private peripherals or coprocessors are released. The physical memory allocated to the killed application segments is not released.
    99 
    100  === 2) void '''giet_exec_application'''( char* name ) ===
    101 This function starts execution for the the application identified by the vspace '''name''' argument.
     96 === 1) void '''giet_exec_application'''( char* vspace_name ) ===
     97This function starts execution for the the application identified by the <vspace_name> argument.
    10298The application  data segments are (re)loaded into memory from the .elf file.
    10399Only thread that has the ''is_main'' flag set  in the mapping is activated.
    104100
    105 === 3) void '''get_applications_status'''( ) ===
    106 This function display on kernel TTY0, for all registered vspace, the status of each thread defined in the space.
    107 
     101 === 2) void '''giet_kill_application'''( char* vspace_name ) ===
     102This function kill the application identified by the <vspace_name> argument:
     103All application threads defined in the mapping receive a KILL signal and will be deactivated at the next context switch. The private peripherals or coprocessors are released. The physical memory allocated to the killed application segments is not released.
     104
     105=== 3) void '''get_applications_status'''( char* vspace_name ) ===
     106This function displays, for application identified by the  <vspace_name> argument, the status of each thread defined in the vspace.
     107If the <vspace_name> argument is NULL, it displays the status of all mapped applications.
    108108
    109109 ==  __Coprocessors related system calls__ ==
    110110
    111 The GIET_VM allows user applications to use hardware accelerators (called coprocessors). These coprocessors can be distributed in the architecture, but there is at most one coprocessor per cluster. To be supported by the GIET_VM, a coprocessor must use the '''vci_mwmr_dma''' component, that is a generic multi-channels DMA controller.
    112 
    113 The '''vci_mwmr_dma''' component provide to coprocessor a variable number of TO_COPROC or FROM_COPROC ports, that implement FIFO interfaces. Coprocessor can request to transfer one or several bursts of 32 bits words, without address. The burst size (generally a cache line), the number of TO_COPROC and FROM_COPROC ports, and the number of bursts for a given port are hardware parameters, depending on the coprocessor type. Each port define a private communication channel between the coprocessor and a user memory buffer. The total number of channels cannot be larger than 16. A channel is identified by an index, and the TO_COPROC channels have the smallest indexes.
     111The GIET_VM allows an user applications to use hardware accelerators (called coprocessors). These coprocessors can be distributed in the architecture, but there is at most one coprocessor per cluster. To be supported by the GIET_VM, a coprocessor must use the '''vci_mwmr_dma''' component, that is a generic multi-channels DMA controller.
     112
     113The '''vci_mwmr_dma''' component provides to a coprocessor a variable number of TO_COPROC or FROM_COPROC ports, that implement FIFO interfaces. Coprocessor can request to transfer one or several bursts of 32 bits words, without address. The burst size (generally a cache line), the number of TO_COPROC and FROM_COPROC ports, and the number of bursts for a given port are hardware parameters, depending on the coprocessor type. Each port define a private communication channel between the coprocessor and a user memory buffer. The total number of channels cannot be larger than 16. A channel is identified by an index, and the TO_COPROC channels have the smallest indexes.
    114114
    115115The user application must use the ''giet_coproc_alloc()'' system call to get a private hardware coprocessor. Then it must use the ''giet_coproc_channel_init()'' system call to configure the TO_COPROC/FROM_COPROC channels. Finally, the coprocessor and the communication channels are activated by the ''giet_coproc_run()'' system call.