|
|
|
|
|
|
|
|
|
|
xen-ppc-devel
[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
|
<Prev in Thread] |
Current Thread |
[Next in Thread> |
- [XenPPC] FYI: more "of_handler" firmware notes,
Hollis Blanchard <=
|
|
|
|
|