Inline
> Well, actually, I was thinking of something along the lines of Lisaac:perhaps i wasn't clear. so please forgive me for repeating
> "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
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