Framebuffer (was [Xen-devel] Xen port of ReactOS)

[James H. <jam...@be...>]

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.

James

> -----Original Message-----
> From: xen...@li... [mailto:xen-devel-
> ad...@li...] On Behalf Of Ge van Geldorp
> Sent: Friday, 25 March 2005 02:52
> To: 'ReactOS Development List'; xen...@li...
> Subject: [Xen-devel] Xen port of ReactOS
>=20
> Hello,
>=20
> 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
> (http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html).
>=20
> 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
> large
> parts of ReactOS (everything except for hardware drivers and some low-
> level
> memory management) inside Xen. It will also give ReactOS access to =
some
> hardware not natively supported yet (by using the Linux driver). The
> benefit
> for Xen at this stage would be the development of ReactOS device =
drivers
> for
> interfacing
> 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
> drivers
> (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
> more
> importantly, I think it's a cool project :-)
>=20
> 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.
> The
> game plan is just start working from the boot code, until a problem is
> hit.
> Fix that problem and continue until the next problem.
>=20
> Any support and help from the Xen and ReactOS communities are of =
course
> greatly appreciated.
>=20
> G=E9 van Geldorp.
>=20
>=20
>=20
> -------------------------------------------------------
> 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.
> Register
> by 3/29 & save $300 =
http://ads.osdn.com/?ad_idh83&alloc_id=15149&op=3Dick
> _______________________________________________
> Xen-devel mailing list
> Xen...@li...
> https://lists.sourceforge.net/lists/listinfo/xen-devel