[movitz-devel] Re: implementing the process abstraction in movitz

[Pascal J.Bourguignon]

Frode Vatvedt Fjeld writes:
> Muli Ben-Yehuda <mulix at mulix.org> writes:
> 
> > The ultimate term goal is a full POSIX / Linux emulation layer for
> > movitz that would allow you to run unmodified Linux binaries. Since
> > this is a very big undertaking, my short term goals are the
> > following basic operations
> >
> > - fork - set up a new context. Open questions are whether it supports
> > seperate address spaces (process or threads?) and whether it supports
> > memory protections (user context vs. kernel context).
> 
> I think if your goal really is linux emulation, then you really need
> to set up an address-space with paging etc. Make a (defclass
> linux-process ..) that plays abuot the same role as the linux "proc"
> structure (or something like that, I don't really remember its
> name..), and your fork must essentially do the same as linux fork
> does. Although I'd model it in terms of some initialization method on
> linux-process, where fork initializes an instance as a copy of another
> process. I'd start off by making some accessors to the paging
> hardware, and build on that.

It seems to me that if the goal is Linux, it would be much better to
approach it from the virtual machine point of view: provide a hardware
abstraction layer, and adapt UML, User-Mode-Linux (or Linux using
User-Mode-linux as a model) to your hardware abstraction virtual
machine.  At most, you'll have to write a couple of Linux
drivers. (Some inspiration could be got from MOL, Macintosh-On-Linux
too).

Then it'll be possible to port any OS to this Movitz Virtual Machine.

This could simplify the driver problem too, since the virtualizer
could just arbitrate (some) hardware access to the guest OSes. We'd
need drivers only for the hardware used directly by Movitz.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
The world will now reboot; don't bother saving your artefacts.