[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [XenPPC] FYI: more "of_handler" firmware notes
A while back I mentioned some of the issues around our "of_handler" directory; the in-domain Open Firmware client interface that makes Xen hcalls. One of the options was to drop it entirely, since we could have Xen provide a device tree in Linux's "flattened" format. However, I think we do want to keep it long-term, especially since it would be poor form to lock out non-Linux guests. To solve the immediate issue, I copied some of rhype's lib code into of_handler, removing our dependence on xen/common/*. I think it's reasonable to have our firmware buildable standalone, like the Bochs "vgabios" or whatever the Xen HVM guys are using. We may even want to make a separate tree for the client interface code. We will need the domain building tools in dom0 to copy it into new domains, and how that's packaged is an unanswered question. I'm also planning to rename the directory, since I especially hate "of" in lowercase as an abbreviation. I'm leaning towards "clientinterface" right now, but "firmware" is also a possibility. However, we could someday add Xen support to other firmwares like SLOF... that would allow users to run a bootloader to select the kernel for their domU without needing access to dom0 (this is a topic of some discussion for Xen/x86 right now as well). Of course, we will still want to move the client interface to use the flattened device tree as the Xen/firmware interface. The firmware would then provide the standard IEEE1275 client interface to the OS. This is on the todo list on the wiki. -- Hollis Blanchard IBM Linux Technology Center _______________________________________________ Xen-ppc-devel mailing list Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-ppc-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |