From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <4cd4c87cb8529f8749aa97b7f5faef58@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Sun, 18 Jan 2009 18:52:57 -0500
To: 9fans@9fans.net
In-Reply-To: <283f5df10901181537r6e69f263j2625281a168f0dbe@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] =?utf-8?q?Les_Mis=C3=A9rables?=
Topicbox-Message-UUID: 8287c4e0-ead4-11e9-9d60-3106f5b1d025

> Well, actually, I was thinking of something along the lines of Lisaac:
> "dynamic" modules are statically compiled ala object files, & the run time
> handles issues between Plan9 & Inferno. Sys->load & the like would not be
> dynamic, but would work as expected. Hell, it could even just be a
> .Net/perl2exe clone: every binary is just an ultra-cut down Dis + compiled
> modules. I like the Lisaac model better, and that's where I was hedging my
> bets; I have a bunch of notes on my local Inferno install, but nothing to
> show due to more pressing issues. C'est la vie.
> & debugging this would require a 9Limbo-aware debugger; the .Net-style
> approach could serve a /lproc or the like though (not that the native one
> couldn't, but the VMish approach could have hooks for stopping execution).
> $0.02

perhaps i wasn't clear.  so please forgive me for repeating
myself and charles.

this is exactly the type approach that i was pointing out
would not work.  it won't work because inferno provides an
environment.  the inferno vm will not be able to replicate
the environment without also dragging large parts of the
inferno kernel along.  but the consequence of doing this
will make inferno procs fundamentally different from
plan 9 procs.

if you're not convinced of this, try this thought experiment.
suppose an inferno proc accesses a # device.  and suppose
further that this device is different in plan 9 and inferno.
how do you bridge the cap in both directions so that neither
inferno nor plan 9 is aware of the joke?

- erik