OLD | NEW |
(Empty) | |
| 1 About |
| 2 ===== |
| 3 |
| 4 This directory contains the services required to execute both nexes and pexes. |
| 5 |
| 6 Using |
| 7 ===== |
| 8 |
| 9 For information about how to build and use nexes and pexes from within Mojo, |
| 10 refer to the `mojo/nacl` directory. |
| 11 |
| 12 Non-SFI Nexe Content Handler |
| 13 ---------------------------- |
| 14 |
| 15 The nexe content handler is simple. It: |
| 16 |
| 17 1. Acquires the desired nexe and dumps it into a temporary file, |
| 18 2. Accesses the MojoHandle connecting the content handler to the shell, and |
| 19 3. Launches the Non-SFI nexe. |
| 20 |
| 21 Non-SFI Pexe Content Handler |
| 22 ---------------------------- |
| 23 |
| 24 The pexe content handler is slightly more complex. Although it is similar |
| 25 in structure to the Non-SFI nexe content handler, it has an additional step |
| 26 between item 1 and 2: convert the incoming pexe into a nexe. |
| 27 |
| 28 This pexe to nexe translation requires two steps: compilation and linking. |
| 29 For each of these steps, a helper service is launched. These helper services |
| 30 are actually executed as nexes -- `pnacl_llc.nexe` and `ld.nexe`. The |
| 31 translation done by these nexes is executed as part of a callback to IRT |
| 32 functions, `nacl_irt_private_pnacl_translator_compile`, and |
| 33 `nacl_irt_private_pnacl_translator_link`. This makes communication between |
| 34 the content handler and these helper nexes more complicated. |
| 35 |
| 36 For the full picture of the compilation process: |
| 37 |
| 38 * PexeContentHandler |
| 39 * Create a message pipe, which has a parent and child handle |
| 40 * Call `PexeCompilerStart`, passing in the child end of the message pipe. This |
| 41 contacts a new service which is responsible for launching `pnacl_llc.nexe`. |
| 42 * PexeCompiler (new process) |
| 43 * Launch the pnacl_llc nexe using the child end of the pipe received from the |
| 44 PexeContentHandler |
| 45 * The pnacl_llc nexe uses the IRT to make a call to ServeTranslateRequest |
| 46 (defined in `mojo/nacl/nonsfi/irt_pnacl_translator_compile.cc`). This creates |
| 47 the `PexeCompiler` service, which is ready to handle a single request. It is |
| 48 bound to the child end of the pipe. |
| 49 * Meanwhile, back in the PexeContentHandler: |
| 50 * Bind the parent end of the pipe to a `PexeCompiler` service. Now, |
| 51 `PexeCompile` can be called with inputs defined by a mojom interface, and |
| 52 outputs can be received via callback |
| 53 * Call `PexeCompile`, passing in the name of the pexe, and receiving the |
| 54 object files created by compilation |
| 55 * Meanwhile, back in the pnacl_llc nexe: |
| 56 * Actually do the requested compilation, and pass back the newly created |
| 57 object files |
| 58 |
| 59 The linking process works similarly, but utilizes a different interface which |
| 60 lets it receive object files and return a linked nexe. |
| 61 |
| 62 Once both the compilation and linking steps have been completed, the |
| 63 PexeContentHandler is able to launch the requested nexe. |
| 64 |
| 65 TODO |
| 66 ==== |
| 67 |
| 68 * Turn the NexeContentHandler, PexeContentHandler, PexeCompiler, and |
| 69 PexeLinker services into "anti-singletons". When each service is requested, a |
| 70 unique process must be created. |
| 71 * Use subzero (a NaCl project to improve translation speed) for pexe |
| 72 translation. |
| 73 * Enable caching of translated pexes. |
OLD | NEW |