[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Darwin Advice?
> I know this comes up periodically, but I don't think it has been discussed > since the introduction of Xen 3.0. There have been recent discussions on the Darwin kernel mailing list, so if you decide to go ahead with this, or have darwin-related architectural questions, that would be a good place to post too. > I am part of a group of three graduate > students who are planning to port the Darwin OS to run on Xen as a project > for an operating systems class. That would be funky. > Officially, this is just to get Darwin up > and running, but getting OS X running under Xen would be a fun bonus. That'd be really cool :-) A few points: 1) whether this is "allowed" by Apple will depend on the interpretation of the license agreement - worth checking out 2) You'd have to deal with Apple's protection measures to ensure their OS only runs on their hardware. On PPC OS X it was possible to run with a kernel you'd built yourself, on x86 I'm not sure if this is doable (for a while the open source Darwin/x86 had been left behind by changes in the MacOS X one, and they weren't driver compatible) > First, we are wondering if porting Darwin is even necessary or > "interesting" anymore, now that Intel has hardware virtualization support. Well, I'm not sure to what extent it would be "new" in terms of *research*, although nobody has a complete microkernel based OS running on Xen (although Darwin's XNU is not really a microkernel AFAIK). I'm not sure how big the userbase would be, but new ports are good fun - particularly if it brought OS X closer to running on Xen... :-) > Second, we are looking for technical advice and/or resources from anyone > who has experience porting kernels to Xen, or who knows about > Darwin/Mach/BSD issues. You may be able to leverage code from the NetBSD port of Xen, although I believe Darwin uses a different driver API, which you might need to port to. There is BSD-alike licensed driver and startup code in the Xen tree (see the Minios and the Linux frontend drivers) that you could leverage as a starting point. A possible "way in" might be to work at getting paravirtualised drivers working to accelerate IO in a fully virtualised machine (you'd need to test if Darwin actually runs in Xen's HVM mode first and fix any problems with reference to this list!). You'd have to write some extra stuff (e.g. the driver for the Xen fake PCI device) in order to make this work, but it would be useful for people wanting to accelerate fully virtualised Darwin, and might get you a bit closer to having the paravirtualised drivers working properly... (I'm not sure how similar to the fully paravirtualised case the PV-on-HVM driver code is but I think it should be a step in the right direction!) > Finally, if we don't end up going the Darwin route, > we are open to suggestions for other Xen-related projects that are > interesting and technically challenging. There was a roadmap document posted to the list last year that still contains plenty of work-in-progress stuff, as well as things that have yet to be implemented. You might find something in there. I don't have a link but it'll be in the archives - it was posted by Ian Pratt last summer/autumn IIRC. One thing off the top of my head (probably fairly difficult): adapting Xen to allow owners of domains to carve up their memory and CPU allocation and start domains of their own. This could allow users of virtual machines to start their own domains without allowing them to circumvent resource restrictions. Lots of other stuff in that document though, and you may find help and suggestions on this mailing list. Cheers, Mark -- Dave: Just a question. What use is a unicyle with no seat? And no pedals! Mark: To answer a question with a question: What use is a skateboard? Dave: Skateboards have wheels. Mark: My wheel has a wheel! _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |