Fwiw, I think a ReactOS port would be very useful to both projects.
One thing I think xen could do with (if it isn't there already) is some sort of
virtual framebuffer like with disk and network. Dom0 could provide the backend
of the virtual framebuffer (on virtual consoles or inside X windows or
whatever), and the other domains could make use of the exported framebuffers.
It wouldn't be great for performance, but would provide a simple interface to
the other domains, and be reasonably migratable.
> -----Original Message-----
> From: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:xen-devel-
> admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Ge van Geldorp
> Sent: Friday, 25 March 2005 02:52
> To: 'ReactOS Development List'; xen-devel@xxxxxxxxxxxxxxxxxxxxx
> Subject: [Xen-devel] Xen port of ReactOS
> After doing some research, I've decided to go ahead and start a port of
> ReactOS to Xen. For those in the Xen community not familiar with ReactOS:
> it's an open-source (GPL) re-implementation of the Microsoft Windows
> NT-based line of operating systems, aiming to provide binary compatibility
> for both applications and drivers
> (http://www.reactos.com). For those in the ReactOS community not familiar
> with Xen: it's an open-source (GPL) virtual machine monitor that supports
> execution of multiple guest operating systems with unprecedented levels of
> performance and resource isolation
> Initially I'll focus on getting ReactOS running as a guest OS. This should
> benefit ReactOS primarily, since this will make it possible to develop
> parts of ReactOS (everything except for hardware drivers and some low-
> memory management) inside Xen. It will also give ReactOS access to some
> hardware not natively supported yet (by using the Linux driver). The
> for Xen at this stage would be the development of ReactOS device drivers
> with Xen, which could also be used for a Windows XP port. On the longer
> term, I see no reason why ReactOS couldn't function as a driver domain. As
> driver compatibility improves in ReactOS, this could provide Xen guests
> access to hardware for which the manufacturer provides only Windows
> (due to Xens nature, not every driver
> could be used this way, but I bet a large percentage of the drivers depend
> on the kernel to do the really low-level stuff).
> All in all, it seems a win-win proposition for both projects. And even
> importantly, I think it's a cool project :-)
> I've made a branch in ReactOS svn, svn://svn.reactos.com/branches/xen, for
> this port. Of course, the goal is to merge the changes into trunk
> eventually. I expect the port to take at least a few months, my initial
> feeling is that it should be done by the end of the year (there's lots of
> other stuff in ReactOS I want to work on too). The wiki page at
> http://wiki.reactos.com/Xen_port will be used to keep track of progress.
> game plan is just start working from the boot code, until a problem is
> Fix that problem and continue until the next problem.
> Any support and help from the Xen and ReactOS communities are of course
> greatly appreciated.
> Gé van Geldorp.
> This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
> Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
> Embedded(r) & Windows Mobile(tm) platforms, applications & content.
> by 3/29 & save $300 http://ads.osdn.com/?ad_idh83&alloc_id149&op=ick
> Xen-devel mailing list
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
Xen-devel mailing list