Connect PPAPI IPC channels for non-SFI mode.

ppapi/native_client/src/trusted/plugin/plugin.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifdef _MSC_VER
 // Do not warn about use of std::copy with raw pointers.
 #pragma warning(disable : 4996)
 #endif
 
 #include "ppapi/native_client/src/trusted/plugin/plugin.h"
@@ skipping 367 matching lines @@
                             true /* should_report_uma */,
                             params, init_done_cb, crash_cb)) {
     return false;
   }
   PLUGIN_PRINTF(("Plugin::LoadNaClModule (%s)\n",
                  main_subprocess_.detailed_description().c_str()));
   return true;
 }
 
 bool Plugin::LoadNaClModuleContinuationIntern(ErrorInfo* error_info) {
+#if 0

[Mark Seaborn, 2014/02/07 23:54:10]

So the trusted plugin will need to know whether we're using Non-SFI Mode if
we're going to turn this into a runtime check.

I think we need to have the browser tell the renderer (and trusted plugin)
whether Non-SFI Mode is enabled.  This probably needs to be plumbed through via
ppapi/c/private/ppb_nacl_private.h.

In the long term, the trusted plugin needs to know something about Non-SFI Mode
anyway.  Eventually we'll want to have separate "arm" and "arm-nonsfi" entries
in the NaCl manifest files.  The question would be whether we want to start
implementing that yet.  Even if we have that, I think the plugin still needs to
know whether to ignore the "arm-nonsfi" entry based on whether Non-SFI Mode is
enabled/disabled browser-wide.

Another option here is to implement enough of the SRPC "reverse service" stuff
in components/nacl/loader/nonsfi/nonsfi_main.cc such that StartSrpcServices()
here succeeds.  I'm reluctant to recommend doing that, given that the code for
that will have a limited lifetime.

[hidehiko, 2014/02/10 08:18:34]

Thank you for pointing this out.
So, I think this is the next work I should focus on. (I'm planning to exclude
the part from the pepper-connection CL which will be sent to the code review).

My understanding is that:

Currently, the browser has a flag, and it checks if the plugin is non-sfi mode
or not. (i.e., all NaCl plugin runs non-sfi mode, right now).

Instead, we'd probably like to;
- pass the flag to the renderer somehow (by directly passing the flag or using
private ppapi as you suggested?)
- if non-sfi mode is enabled and there is an entry for "***-nonsfi" in NMF, the
rednerer sends a message to launch non-sfi NaCl.
- Considering that we'll eventually split the nacl_helper binary and
bare_metal_helper binary, it is necessary for the renderer to know if non-sfi is
enabled or not at very beginning of the NaCl plugin initialization, in order to
tell browser/zygote to launch the appropriate binary.


As for reimplementing SRPC "reverse service", IIUC it is for the
irt_resource_open implementation. Is it correct? If so, actually we need to have
the IRT, so we need either 1) waiting for SRPC replacement or 2) reusing the
current SRPC service for a short term solution. IMHO it's up to when SRPC will
be retired?

So, if we need to use SRPC somehow (before the retire), "working on it first,
then working on the implementation of non-sfi switching on the renderer" may be
an option. WDYT?

[Mark Seaborn, 2014/02/10 18:57:35]

Yes.
Yes, but this is not necessary for the current change.
You mean at browser startup?  It's not really up to the renderer to tell the
browser what zygote processes to launch at startup.
Yes.
Right.  For open_resource(), I'm inclined to wait for Justin TerAvest to
refactor this to use Chrome IPC before we try to hook this up to Non-SFI Mode. 
But that will involve co-ordinating with Justin.
Well, whichever way things go, the trusted plugin will eventually need to know
whether Non-SFI Mode is enabled.  So I think it makes most sense to plumb that
through to the trusted plugin now, and not add any more SRPC code to
components/nacl/loader/nonsfi/ for now.

   if (!main_subprocess_.StartSrpcServices()) {
     // The NaCl process probably crashed. On Linux, a crash causes this error,
     // while on other platforms, the error is detected below, when we attempt to
     // start the proxy. Report a module initialization error here, to make it
     // less confusing for developers.
     NaClLog(LOG_ERROR, "LoadNaClModuleContinuationIntern: "
             "StartSrpcServices failed\n");
     error_info->SetReport(ERROR_START_PROXY_MODULE,
                           "could not initialize module.");
     return false;
   }
+#endif
   PP_ExternalPluginResult ipc_result =
       nacl_interface_->StartPpapiProxy(pp_instance());
   if (ipc_result == PP_EXTERNAL_PLUGIN_OK) {
     // Log the amound of time that has passed between the trusted plugin being
     // initialized and the untrusted plugin being initialized.  This is
     // (roughly) the cost of using NaCl, in terms of startup time.
     HistogramStartupTimeMedium(
         "NaCl.Perf.StartupTime.NaClOverhead",
         static_cast<float>(NaClGetTimeOfDayMicroseconds() - init_time_)
             / NACL_MICROS_PER_MILLI);
@@ skipping 1178 matching lines @@
   DCHECK(pp::Module::Get()->core()->IsMainThread());
   DCHECK(nacl_interface_);
   exit_status_ = exit_status;
   nacl_interface_->SetReadOnlyProperty(pp_instance(),
                                        pp::Var("exitStatus").pp_var(),
                                        pp::Var(exit_status_).pp_var());
 }
 
 
 }  // namespace plugin