Launch nexes from mojo_shell.

Launch Native Client executables from mojo_shell.

Only works on x64 and the shell is killed when a .nexe exits.

BUG=401761

[Nick Bray (chromium), 2015-01-28 22:54:13]

ncbray@chromium.org changed reviewers:
+ jamesr@chromium.org

[Nick Bray (chromium), 2015-01-28 22:54:13]

Are you the best person to review this?

[jamesr, 2015-01-28 23:11:31]

https://codereview.chromium.org/884303002/diff/40001/mojo/nacl/monacl_shell.cc
File mojo/nacl/monacl_shell.cc (right):

https://codereview.chromium.org/884303002/diff/40001/mojo/nacl/monacl_shell.c...
mojo/nacl/monacl_shell.cc:27: MOJO_HANDLE_INVALID);
MOJO_INVALID_HANDLE ?

https://codereview.chromium.org/884303002/diff/40001/shell/dynamic_applicatio...
File shell/dynamic_application_loader.cc (right):

https://codereview.chromium.org/884303002/diff/40001/shell/dynamic_applicatio...
shell/dynamic_application_loader.cc:116:
AsPath(context_->task_runners()->blocking_pool(),
hmm, wouldn't it make more sense to check for .nexe here along with the shebang
and mimetype sniffing?

https://codereview.chromium.org/884303002/diff/40001/shell/dynamic_applicatio...
shell/dynamic_application_loader.cc:151: nacl_runner_ =
scoped_ptr<NaClServiceRunner>(
nacl_runner_.reset(new ....);

https://codereview.chromium.org/884303002/diff/40001/shell/dynamic_applicatio...
shell/dynamic_application_loader.cc:153: nacl_runner_->Start(path,
application_request_.Pass());
add a return; here and leave the last bit un-indented

https://codereview.chromium.org/884303002/diff/40001/shell/dynamic_applicatio...
shell/dynamic_application_loader.cc:156: ReportComplete();
return;

https://codereview.chromium.org/884303002/diff/40001/shell/nacl/nacl_service_...
File shell/nacl/nacl_service_runner.cc (right):

https://codereview.chromium.org/884303002/diff/40001/shell/nacl/nacl_service_...
shell/nacl/nacl_service_runner.cc:14: Context* context)
looks oddly wrapped - did you 'git cl format' ?

https://codereview.chromium.org/884303002/diff/40001/shell/nacl/nacl_service_...
shell/nacl/nacl_service_runner.cc:48: 0, NULL, handle);
nullptr ?

https://codereview.chromium.org/884303002/diff/40001/shell/nacl/nacl_service_...
File shell/nacl/nacl_service_runner.h (right):

https://codereview.chromium.org/884303002/diff/40001/shell/nacl/nacl_service_...
shell/nacl/nacl_service_runner.h:20: class NaClServiceRunner : public
base::DelegateSimpleThread::Delegate {
why isn't this a DynamicServiceRunner?

https://codereview.chromium.org/884303002/diff/40001/shell/nacl/nacl_service_...
shell/nacl/nacl_service_runner.h:22: NaClServiceRunner(Context* context);
explicit

[Nick Bray (chromium), 2015-01-29 22:31:35]

https://codereview.chromium.org/884303002/diff/40001/mojo/nacl/monacl_shell.cc
File mojo/nacl/monacl_shell.cc (right):

https://codereview.chromium.org/884303002/diff/40001/mojo/nacl/monacl_shell.c...
mojo/nacl/monacl_shell.cc:27: MOJO_HANDLE_INVALID);
On 2015/01/28 23:11:30, jamesr wrote:
> MOJO_INVALID_HANDLE ?

Grep shows no such beast?  I believe this is the correct name.

https://codereview.chromium.org/884303002/diff/40001/shell/dynamic_applicatio...
File shell/dynamic_application_loader.cc (right):

https://codereview.chromium.org/884303002/diff/40001/shell/dynamic_applicatio...
shell/dynamic_application_loader.cc:116:
AsPath(context_->task_runners()->blocking_pool(),
On 2015/01/28 23:11:30, jamesr wrote:
> hmm, wouldn't it make more sense to check for .nexe here along with the
shebang
> and mimetype sniffing?

Done.

https://codereview.chromium.org/884303002/diff/40001/shell/dynamic_applicatio...
shell/dynamic_application_loader.cc:151: nacl_runner_ =
scoped_ptr<NaClServiceRunner>(
On 2015/01/28 23:11:30, jamesr wrote:
> nacl_runner_.reset(new ....);

Done.

https://codereview.chromium.org/884303002/diff/40001/shell/dynamic_applicatio...
shell/dynamic_application_loader.cc:153: nacl_runner_->Start(path,
application_request_.Pass());
On 2015/01/28 23:11:30, jamesr wrote:
> add a return; here and leave the last bit un-indented

Done.

https://codereview.chromium.org/884303002/diff/40001/shell/dynamic_applicatio...
shell/dynamic_application_loader.cc:156: ReportComplete();
On 2015/01/28 23:11:30, jamesr wrote:
> return;

Done.

https://codereview.chromium.org/884303002/diff/40001/shell/nacl/nacl_service_...
File shell/nacl/nacl_service_runner.cc (right):

https://codereview.chromium.org/884303002/diff/40001/shell/nacl/nacl_service_...
shell/nacl/nacl_service_runner.cc:14: Context* context)
On 2015/01/28 23:11:30, jamesr wrote:
> looks oddly wrapped - did you 'git cl format' ?

Done.

The code in the NaCl repo is too far gone to use this tool so I am not in the
habit... but I think I may have found my new best friend.

https://codereview.chromium.org/884303002/diff/40001/shell/nacl/nacl_service_...
shell/nacl/nacl_service_runner.cc:48: 0, NULL, handle);
On 2015/01/28 23:11:30, jamesr wrote:
> nullptr ?

Done.

https://codereview.chromium.org/884303002/diff/40001/shell/nacl/nacl_service_...
File shell/nacl/nacl_service_runner.h (right):

https://codereview.chromium.org/884303002/diff/40001/shell/nacl/nacl_service_...
shell/nacl/nacl_service_runner.h:20: class NaClServiceRunner : public
base::DelegateSimpleThread::Delegate {
On 2015/01/28 23:11:30, jamesr wrote:
> why isn't this a DynamicServiceRunner?

Because DynamicServiceRunner has assumptions about shared libraries baked in:

https://github.com/domokit/mojo/blob/671001e79618e4e1445524af66356144444984fd...

I could either ignore this method (meh), or factor out a "DynlibServiceRunner"
class that contains it.  Semi-unrelated, but I had been thinking about trying to
move all the files that assume dynamic libraries into //shell/dynlib or
something like that.  Splitting the base class could be part of that move.

https://codereview.chromium.org/884303002/diff/40001/shell/nacl/nacl_service_...
shell/nacl/nacl_service_runner.h:22: NaClServiceRunner(Context* context);
On 2015/01/28 23:11:30, jamesr wrote:
> explicit

Done.

[jamesr, 2015-01-29 22:32:04]

https://codereview.chromium.org/884303002/diff/40001/mojo/nacl/monacl_shell.cc
File mojo/nacl/monacl_shell.cc (right):

https://codereview.chromium.org/884303002/diff/40001/mojo/nacl/monacl_shell.c...
mojo/nacl/monacl_shell.cc:27: MOJO_HANDLE_INVALID);
On 2015/01/29 22:31:34, Nick Bray (chromium) wrote:
> On 2015/01/28 23:11:30, jamesr wrote:
> > MOJO_INVALID_HANDLE ?
> 
> Grep shows no such beast?  I believe this is the correct name.

That's not what I meant - why are we passing an invalid handle in here?

[Nick Bray (chromium), 2015-01-29 22:34:54]

https://codereview.chromium.org/884303002/diff/40001/mojo/nacl/monacl_shell.cc
File mojo/nacl/monacl_shell.cc (right):

https://codereview.chromium.org/884303002/diff/40001/mojo/nacl/monacl_shell.c...
mojo/nacl/monacl_shell.cc:27: MOJO_HANDLE_INVALID);
On 2015/01/29 22:32:03, jamesr wrote:
> On 2015/01/29 22:31:34, Nick Bray (chromium) wrote:
> > On 2015/01/28 23:11:30, jamesr wrote:
> > > MOJO_INVALID_HANDLE ?
> > 
> > Grep shows no such beast?  I believe this is the correct name.
> 
> That's not what I meant - why are we passing an invalid handle in here?

Because this is a test rig for running the embedder unit tests and there is no
initial handle to connect to.

[jamesr, 2015-01-29 23:41:23]

https://codereview.chromium.org/884303002/diff/80001/mojo/public/platform/nac...
File mojo/public/platform/nacl/BUILD.gn (right):

https://codereview.chromium.org/884303002/diff/80001/mojo/public/platform/nac...
mojo/public/platform/nacl/BUILD.gn:15: "mojo/nacl:mojo",
nothing in //mojo/public should depend on targets outside of //mojo/public,
which AFAIKT this is.  I don't see any #includes for this path - what is the
intent here?

https://codereview.chromium.org/884303002/diff/80001/shell/BUILD.gn
File shell/BUILD.gn (right):

https://codereview.chromium.org/884303002/diff/80001/shell/BUILD.gn#newcode203
shell/BUILD.gn:203: data_deps = []
you don't need to have this

https://codereview.chromium.org/884303002/diff/80001/shell/BUILD.gn#newcode214
shell/BUILD.gn:214: data_deps += [
"//native_client/src/untrusted/irt:irt_core(//native_client/build/toolchain/nacl:irt_${cpu_arch})"
]
and you can just say data_deps = [] here

https://codereview.chromium.org/884303002/diff/80001/shell/nacl/nacl_service_...
File shell/nacl/nacl_service_runner.h (right):

https://codereview.chromium.org/884303002/diff/80001/shell/nacl/nacl_service_...
shell/nacl/nacl_service_runner.h:23: virtual ~NaClServiceRunner();
spell this:

~NaClServiceRunner() override;

[Nick Bray (chromium), 2015-01-29 23:54:55]

https://codereview.chromium.org/884303002/diff/80001/mojo/public/platform/nac...
File mojo/public/platform/nacl/BUILD.gn (right):

https://codereview.chromium.org/884303002/diff/80001/mojo/public/platform/nac...
mojo/public/platform/nacl/BUILD.gn:15: "mojo/nacl:mojo",
On 2015/01/29 23:41:23, jamesr wrote:
> nothing in //mojo/public should depend on targets outside of //mojo/public,
> which AFAIKT this is.  I don't see any #includes for this path - what is the
> intent here?

This is a library that defines the public Mojo* C APIs.  Right now the source is
being generated by a script that also generates sources that are going to be
linked into mojo_shell, Chrome, the NaCl IRT etc.  So.... ugly.  This may be a
"chat in person to try and find the right balance"-type issue.

https://codereview.chromium.org/884303002/diff/80001/shell/BUILD.gn
File shell/BUILD.gn (right):

https://codereview.chromium.org/884303002/diff/80001/shell/BUILD.gn#newcode203
shell/BUILD.gn:203: data_deps = []
On 2015/01/29 23:41:23, jamesr wrote:
> you don't need to have this

Done.  Just trying to be idiot proof.

https://codereview.chromium.org/884303002/diff/80001/shell/BUILD.gn#newcode214
shell/BUILD.gn:214: data_deps += [
"//native_client/src/untrusted/irt:irt_core(//native_client/build/toolchain/nacl:irt_${cpu_arch})"
]
On 2015/01/29 23:41:23, jamesr wrote:
> and you can just say data_deps = [] here

Done.

https://codereview.chromium.org/884303002/diff/80001/shell/nacl/nacl_service_...
File shell/nacl/nacl_service_runner.h (right):

https://codereview.chromium.org/884303002/diff/80001/shell/nacl/nacl_service_...
shell/nacl/nacl_service_runner.h:23: virtual ~NaClServiceRunner();
On 2015/01/29 23:41:23, jamesr wrote:
> spell this:
> 
> ~NaClServiceRunner() override;

Done.

[jamesr, 2015-01-29 23:59:05]

"balance" isn't really the right word here - this patch as checked in will fail
to pass the 'gn gen' step when rolled into chromium since that target will not
exist in the place the build file looks for.

Would code linked against nacl and thus (presumably) using the
//mojo/public/platform/nacl targets want to link against any code from this
target?  If so, where are they supposed to get the source from?  If this code
isn't supposed to link against such apps then the target shouldn't be referenced
from //mojo/public/...

[viettrungluu, 2015-01-30 00:14:17]

On 2015/01/29 23:59:05, jamesr wrote:
> "balance" isn't really the right word here - this patch as checked in will
fail
> to pass the 'gn gen' step when rolled into chromium since that target will not
> exist in the place the build file looks for.
> 
> Would code linked against nacl and thus (presumably) using the
> //mojo/public/platform/nacl targets want to link against any code from this
> target?  If so, where are they supposed to get the source from?  If this code
> isn't supposed to link against such apps then the target shouldn't be
referenced
> from //mojo/public/...

AFAICT, this really means that mojo/nacl:mojo (and thus
mojo/nacl:mojo_nacl_codegen) are in the wrong place, and should be in
public/platform/nacl also (organized suitably).

[qsr, 2015-01-30 15:04:10]

qsr@chromium.org changed reviewers:
+ qsr@chromium.org

[qsr, 2015-01-30 15:04:12]

https://codereview.chromium.org/884303002/diff/40002/shell/dynamic_applicatio...
File shell/dynamic_application_loader.cc (right):

https://codereview.chromium.org/884303002/diff/40002/shell/dynamic_applicatio...
shell/dynamic_application_loader.cc:5: #include
"shell/dynamic_application_loader.h"
I'm probably completely missing a point somewhere here, but why must this be
backed here and not in a content handler? What do you need here today that you
couldn't do in the StartApplication method of a content handler?

https://codereview.chromium.org/884303002/diff/40002/shell/dynamic_applicatio...
shell/dynamic_application_loader.cc:87: virtual GURL URL() = 0;
Instead of this, just pass the URL in the constructor of this class, and expose
is as a const protected member.

https://codereview.chromium.org/884303002/diff/40002/shell/nacl/nacl_service_...
File shell/nacl/nacl_service_runner.cc (right):

https://codereview.chromium.org/884303002/diff/40002/shell/nacl/nacl_service_...
shell/nacl/nacl_service_runner.cc:29:
context_->ResolveShellFileURL("irt_x64/irt_core.nexe").GetContent());
For obvious reason this will fail on Android.

[Nick Bray (chromium), 2015-01-31 02:47:10]

I'll peel out the untrusted bits Monday, just responding to qsr.

https://codereview.chromium.org/884303002/diff/40002/shell/dynamic_applicatio...
File shell/dynamic_application_loader.cc (right):

https://codereview.chromium.org/884303002/diff/40002/shell/dynamic_applicatio...
shell/dynamic_application_loader.cc:5: #include
"shell/dynamic_application_loader.h"
On 2015/01/30 15:04:11, qsr wrote:
> I'm probably completely missing a point somewhere here, but why must this be
> backed here and not in a content handler? What do you need here today that you
> couldn't do in the StartApplication method of a content handler?

It would be possible, but more complex (would need to generate and manage a
tempfile inside the content handler.)  The bigger issue, however, is that
eventually a file-handle-like API will be needed for random access, mmaping the
file in place, etc.  (Trying to treat native executables as data streams will
add ~100-500ms to the initial load time.)  The system will also need to be aware
it's interacting with a "native code loader" so that it opens files with
permissions to be mapped executable.

What that interface will ultimately look like is unclear to me, at the moment. 
It won't be like today's content loader.  Matching what we do for DSO loading is
simple and doesn't add any new concepts, so it works for now.

https://codereview.chromium.org/884303002/diff/40002/shell/dynamic_applicatio...
shell/dynamic_application_loader.cc:87: virtual GURL URL() = 0;
On 2015/01/30 15:04:11, qsr wrote:
> Instead of this, just pass the URL in the constructor of this class, and
expose
> is as a const protected member.

Not entirely convinced, but don't have strong feelings.  This would be the only
protected field in the hierarchy, and it would be the only case where
implementation details about the actual data being loaded would leak lower into
the hierarchy.  Opinions, James?

https://codereview.chromium.org/884303002/diff/40002/shell/nacl/nacl_service_...
File shell/nacl/nacl_service_runner.cc (right):

https://codereview.chromium.org/884303002/diff/40002/shell/nacl/nacl_service_...
shell/nacl/nacl_service_runner.cc:29:
context_->ResolveShellFileURL("irt_x64/irt_core.nexe").GetContent());
On 2015/01/30 15:04:11, qsr wrote:
> For obvious reason this will fail on Android.

Yes.  ARM and x86-32 support will require multiprocess mode.  Keeping things
simple until the complexity is needed.

[Nick Bray (chromium), 2015-02-02 20:48:12]

jamesr: untrusted bit have been peeled out, should be ready for review.
Tell me if you think URL() should become url_.

[jamesr, 2015-02-03 05:15:42]

I don't think optimizing for mmap()ing a local file is terribly wise at this
stage.  Assume that you're always loading streaming off a network and we can
optimize later.  It'll be far easier to understand and tune the system later on
if different systems use a common flow for loading instead of everything making
up its own way.

Today we load all locally compiled services over http no matter how we're
running.

https://codereview.chromium.org/884303002/diff/120001/shell/BUILD.gn
File shell/BUILD.gn (right):

https://codereview.chromium.org/884303002/diff/120001/shell/BUILD.gn#newcode15
shell/BUILD.gn:15: config("gate_nacl") {
it's not worth adding a new config that will be used in only one place. just set
the define directly

https://codereview.chromium.org/884303002/diff/120001/shell/BUILD.gn#newcode205
shell/BUILD.gn:205: sources += [
as in defines += [ .. ] in here (and if you must have the =0 do it in the false
case, although if the #ifs are set up correctly you should not need to)

https://codereview.chromium.org/884303002/diff/120001/shell/dynamic_applicati...
File shell/dynamic_application_loader.cc (right):

https://codereview.chromium.org/884303002/diff/120001/shell/dynamic_applicati...
shell/dynamic_application_loader.cc:31: #if MOJO_USE_NACL
#if defined(MOJO_USE_NACL)

[Nick Bray (chromium), 2015-02-03 19:06:31]

> I don't think optimizing for mmap()ing a local file is terribly wise at this
> stage.  Assume that you're always loading streaming off a network and we can
> optimize later.  It'll be far easier to understand and tune the system later
on
> if different systems use a common flow for loading instead of everything
making
> up its own way.
> 
> Today we load all locally compiled services over http no matter how we're
> running.

Yes... but there will be a net cache.  On disk.  From my view of the elephant,
it really doesn't matter what the URL scheme is, because as an implementation
issue we will be shlepping files for speed.  While I generally agree that
premature optimization is bad, I have spent quite a bit of time making code
loading fast in Chrome so I already have a good idea of how things play out. 
IIRC, treating binaries as data streams has about a ~10ms/MB cost, ~35ms/MB for
NaCl - on a fast desktop.  Assume you're loading 20 MB+ on a cell phone, you're
paying a significant tax in startup time, even with a cache hit.  And you will
also be unable to de-dupe the base memory usage of common binaries (say V8 or
Dart).  At this juncture, if we pretend data streams are all we need, we will be
paying a rather large cost to rework the data loading architecture later.  For
developers we can sell the model that everything is http://, but implementing
the system that way would result in rather shameful performance.  Make things as
simple as possible, but not simpler.

https://codereview.chromium.org/884303002/diff/120001/shell/BUILD.gn
File shell/BUILD.gn (right):

https://codereview.chromium.org/884303002/diff/120001/shell/BUILD.gn#newcode15
shell/BUILD.gn:15: config("gate_nacl") {
On 2015/02/03 05:15:41, jamesr wrote:
> it's not worth adding a new config that will be used in only one place. just
set
> the define directly

Done.

https://codereview.chromium.org/884303002/diff/120001/shell/BUILD.gn#newcode205
shell/BUILD.gn:205: sources += [
On 2015/02/03 05:15:41, jamesr wrote:
> as in defines += [ .. ] in here (and if you must have the =0 do it in the
false
> case, although if the #ifs are set up correctly you should not need to)

Done, although I generally believe using -Wundef is the better choice.

https://codereview.chromium.org/884303002/diff/120001/shell/dynamic_applicati...
File shell/dynamic_application_loader.cc (right):

https://codereview.chromium.org/884303002/diff/120001/shell/dynamic_applicati...
shell/dynamic_application_loader.cc:31: #if MOJO_USE_NACL
On 2015/02/03 05:15:41, jamesr wrote:
> #if defined(MOJO_USE_NACL)

Done.

[jamesr, 2015-02-06 01:27:21]

Is the desire to mmap() the only reason that the nacl loader has to be a special
case here, or are there other considerations?

[Nick Bray (chromium), 2015-02-06 02:08:39]

On 2015/02/06 01:27:21, jamesr wrote:
> Is the desire to mmap() the only reason that the nacl loader has to be a
special
> case here, or are there other considerations?

It's the easiest to articulate.  And I wouldn't say "desire" as much as
"resigned to the fact we'll eventually need it to get acceptable performance." 
Been there, done that before.  Being part of the shell dodges a rather
subjective and hard to resolve discussion about how file handles could be
exposed to Mojo apps.  I'd rather have that discussion with prototypes and data
at hand.  I don't want a hard to resolve discussion to be inserted on the
critical path.  In a world where we had a solid, high performance story for
dealing with file handles in Mojo apps, I'd be much more comfortable with
decoupling from the shell.

A concern that's harder to pin down is how this will interact with multiprocess
mode.  I suspect NaCl support will require shipping a specialized executable for
bringing up the sandbox.  At that point, it won't be a simple content handler no
matter what the interface looks like.  It's also unclear to me how much we'll
interact directly with the embedder, how much functionality we can share with
multiprocess DSO launching, etc.  Being part of the shell keeps options open,
until I better understand all the moving parts.

Interface wise, DSO and nexe loading should look almost identical from the
shell's perspective.  I realize DSO loading isn't where we want it to be, yet,
but I'd rather keep nexe loading beside it to force co-design.

Maybe in a year NaCl loading can be a Mojo app, but right now my design sense is
telling me that's the wrong way to jump.

[Aaron Boodman, 2015-02-06 02:18:54]

On 2015/02/06 02:08:39, Nick Bray (chromium) wrote:
> Maybe in a year NaCl loading can be a Mojo app, but right now my design sense
is
> telling me that's the wrong way to jump.

Why don't we just modify or copy the ContentHandler interface to have another
version that takes a file handle or path? At least then we will be sending code
down similar paths for all kinds of apps. We should do the same thing for DSOs.
Putting awareness of nacl in the shell seems unfortunate to me.

[jamesr, 2015-02-06 02:25:29]

Special-casing speculatively seems like a bad idea to me as well.  I agree there
are lots of reasons that we might want to or need to change loading down the
line, but adding another specialized path in the shell for loading nacl without
it being technically required at this stage will simply slow down all
development of the shell without providing any concrete benefit.

[Nick Bray (chromium), 2015-02-06 03:18:50]

On 2015/02/06 02:18:54, Aaron Boodman wrote:
> On 2015/02/06 02:08:39, Nick Bray (chromium) wrote:
> > Maybe in a year NaCl loading can be a Mojo app, but right now my design
sense
> is
> > telling me that's the wrong way to jump.
> 
> Why don't we just modify or copy the ContentHandler interface to have another
> version that takes a file handle or path? At least then we will be sending
code
> down similar paths for all kinds of apps. We should do the same thing for
DSOs.
> Putting awareness of nacl in the shell seems unfortunate to me.

You can't have a content handler that takes a file handle because Mojo apps
currently lack the concept of a file handle.  You could have a handler that
takes a path, but for the reasons I previously listed you'd want to link the
actual implementation into the shell.  You'd trade a C++ interface for a Mojo
interface and get stymied if you ever wanted to pass a file handle through that
interface.  PNaCl support is going to add even more fun, with an additional app
interceding to translate and an additional layer of caching - so there won't be
a single interface you need to pass files through, they'll chain together.

I think this is the crux: I don't see a clean separation, yet.  I suspect that
_right now_, it simply isn't possible to do a clean separation.  Binary loading
is very close to the metal, and it cuts against the opinionated parts of the
Mojo API.  My current strategy is to build it, maintain a clean integration, and
then try to figure out the most principled way to generalize it.  I understand
where you are coming from.  If I saw a way to fit this into the current concept
of a Mojo app, I would.  But right now I don't.  Figuring this out is a
longer-term task.

I realize I may appear to be monomaniacal on this issue, but from the parts of
the elephant I see so far, trying to shoehorn a NaCl loader into a Mojo app
seems like an awful idea at this juncture.  But this issue keeps popping up
again, and again because it's an appealing mental model.  Would it help if I
scheduled a block of time with a white board and walked through NaCl loading,
lessons learned from Chrome, and what this means for mojo_shell?

[jamesr, 2015-02-06 03:21:25]

You could take a data pipe, read it out to a file on disk, then load from that
in the same way you are doing here.  What part of that won't work?

[jamesr, 2015-02-06 05:07:24]

To expand on that a bit, we're going to need to make a number of changes to
loading in order to support packaging, signing+identify, out of process and
coherent caching.  When we have those we'll need to do a lot of performance
tuning.  We're also currently a bit over-encumbered by different loading paths. 
With that in mind, the only sorts of changes that should happen to loading in
the shell are ones that add fundamental new capabilities that we don't have
today and need in order to make progress in other areas or changes that simplify
things.  This patch doesn't add a fundamental new capability to the shell since
everything it does could be done using existing primitives and it adds another
loading path to worry about which will make accomplishing all of the other goals
I mentioned harder.  This sounds like a bad tradeoff to make.