Add stub PPAPI for launching NaCl's sel_ldr process.

Add stub PPAPI for launching NaCl's sel_ldr process.

In ArcticSea, we're going to load the NaCl plugin in the render process.  The
NaCl plugin needs to create a sel_ldr process to host the NEXE, but when the
plugin lives inside the render process, the plugin is sandboxed, so it can't
create a process.  This API instructs the browser to launch a sel_ldr process
and wire up a bunch of IMC channels between the plugin and the new process.

In reality, the sel_ldr process is just chrome.exe run with a command line flag
that causes it to call NaClMain instead of BrowserMain or RendererMain. 
Previously, NaCl accomplished this task by smuggling a function pointer (cast as
an int) from render_process_impl to the NPAPI NaCl plugin.  Rather than use the
same approach again, we're creating a legit way for the PPAPI plugin to ask the
browser to spawn the sel_ldr process.

In BalticSea, we'll likely run the NaCl plugin out-of-process (e.g., in a PPAPI
process).  In that case, the plugin can just host the NEXE internally, and we'll
be able to remove this interface.


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=69568

[abarth-chromium, 2010-12-16 22:22:33]

This patch is just stubs.  I'll fill in the stubs in the next patch.  Mostly I
just want to make sure we're on the right track.

[brettw, 2010-12-16 22:31:49]

We've been putting the "private" interfaces in the same dir as the
implementation (moved to webkit/plugins/ppapi since your patch). Will this work
for NaCl? It might not, in which case the current location is OK.

[abarth-chromium, 2010-12-16 22:35:47]

On 2010/12/16 22:31:49, brettw wrote:
> We've been putting the "private" interfaces in the same dir as the
> implementation (moved to webkit/plugins/ppapi since your patch). Will this
work
> for NaCl? It might not, in which case the current location is OK.

Ideally, NaCl would depend only on src/ppapi so they can decouple their build
system from Chrome, including chrome/webkit.

[brettw, 2010-12-17 03:34:18]

On Thu, Dec 16, 2010 at 2:35 PM,  <abarth@chromium.org> wrote:
> On 2010/12/16 22:31:49, brettw wrote:
>>
>> We've been putting the "private" interfaces in the same dir as the
>> implementation (moved to webkit/plugins/ppapi since your patch). Will this
>
> work
>>
>> for NaCl? It might not, in which case the current location is OK.
>
> Ideally, NaCl would depend only on src/ppapi so they can decouple their
> build
> system from Chrome, including chrome/webkit.

Sounds reasonable. Can you sync to ToT and use the new naming scheme
for the implementation? (webkit/plugins/ppapi/ppb_nacl_private_impl.*,
PPB_Nacl_Private_Impl for the class, webkit::ppapi namespace).

Brett

[abarth-chromium, 2010-12-17 03:39:03]

On Thu, Dec 16, 2010 at 7:34 PM, Brett Wilson <brettw@chromium.org> wrote:
> On Thu, Dec 16, 2010 at 2:35 PM,  <abarth@chromium.org> wrote:
>> On 2010/12/16 22:31:49, brettw wrote:
>>> We've been putting the "private" interfaces in the same dir as the
>>> implementation (moved to webkit/plugins/ppapi since your patch). Will this
>>
>> work
>>>
>>> for NaCl? It might not, in which case the current location is OK.
>>
>> Ideally, NaCl would depend only on src/ppapi so they can decouple their
>> build
>> system from Chrome, including chrome/webkit.
>
> Sounds reasonable. Can you sync to ToT and use the new naming scheme
> for the implementation? (webkit/plugins/ppapi/ppb_nacl_private_impl.*,
> PPB_Nacl_Private_Impl for the class, webkit::ppapi namespace).

Sure.  I'd be happy to.  :)

Adam

[darin (slow to review), 2010-12-17 06:45:17]

can you say more about how this private interface will be used?

[abarth-chromium, 2010-12-17 06:56:31]

On 2010/12/17 06:45:17, darin wrote:
> can you say more about how this private interface will be used?

You can the backend for the interface here:
http://codereview.chromium.org/5933004/

In ArcticSea, we're going to load the NaCl plugin in the render process.  The
NaCl plugin needs to create a sel_ldr process to host the NEXE, but when the
plugin lives inside the render process, the plugin is sandboxed, so it can't
create a process.  This API instructs the browser to launch a sel_ldr process
and wire up a bunch of IMC channels between the plugin and the new process.

In reality, the sel_ldr process is just chrome.exe run with a command line flag
that causes it to call NaClMain instead of BrowserMain or RendererMain. 
Previously, NaCl accomplished this task by smuggling a function pointer (cast as
an int) from render_process_impl to the NPAPI NaCl plugin.  Rather than use the
same approach again, we're creating a legit way for the PPAPI plugin to ask the
browser to spawn the sel_ldr process.

In BalticSea, we'll likely run the NaCl plugin out-of-process (e.g., in a PPAPI
process).  In that case, the plugin can just host the NEXE internally, and we'll
be able to remove this interface.

[darin (slow to review), 2010-12-17 17:23:52]

On Thu, Dec 16, 2010 at 10:56 PM, <abarth@chromium.org> wrote:

> On 2010/12/17 06:45:17, darin wrote:
>
>> can you say more about how this private interface will be used?
>>
>
> You can the backend for the interface here:
> http://codereview.chromium.org/5933004/
>
> In ArcticSea, we're going to load the NaCl plugin in the render process.
>  The
> NaCl plugin needs to create a sel_ldr process to host the NEXE, but when
> the
> plugin lives inside the render process, the plugin is sandboxed, so it
> can't
> create a process.  This API instructs the browser to launch a sel_ldr
> process
> and wire up a bunch of IMC channels between the plugin and the new process.
>
> In reality, the sel_ldr process is just chrome.exe run with a command line
> flag
> that causes it to call NaClMain instead of BrowserMain or RendererMain.
> Previously, NaCl accomplished this task by smuggling a function pointer
> (cast as
> an int) from render_process_impl to the NPAPI NaCl plugin.  Rather than use
> the
> same approach again, we're creating a legit way for the PPAPI plugin to ask
> the
> browser to spawn the sel_ldr process.
>
> In BalticSea, we'll likely run the NaCl plugin out-of-process (e.g., in a
> PPAPI
> process).  In that case, the plugin can just host the NEXE internally, and
> we'll
> be able to remove this interface.
>
>
Makes sense, thanks!  I am a bit sad to see the ppapi/c/private directory,
but
I can't think of a better solution.

-Darin



>
> http://codereview.chromium.org/5897004/
>

[abarth-chromium, 2010-12-17 19:23:08]

Merged to TOT.

[abarth-chromium, 2010-12-17 19:58:19]

On 2010/12/17 19:23:08, abarth wrote:
> Merged to TOT.

I landed this so we can make progress.  Let me know if you'd like anything
tweaked after the merge to TOT.

[brettw, 2010-12-17 20:09:52]

LGTM. I think PPB_NaCl would be a more consistent name than PPB_NaClUtil to go
with PPB_Flash and PPB_PDF which we already have. Can you make this change when
you have the chance?

[abarth-chromium, 2010-12-17 20:28:29]

On 2010/12/17 20:09:52, brettw wrote:
> LGTM. I think PPB_NaCl would be a more consistent name than PPB_NaClUtil to go
> with PPB_Flash and PPB_PDF which we already have. Can you make this change
when
> you have the chance?

Sure.  I'd be happy to.