This is mostly for Richard Miller but I don't have his email. But if you are interested in Xen, read along.
We have an ok xen environment going. Why are we doing this? Per a certain person at xyz.com, we are looking at giving people a usable xen-based plan 9 environment, and at the same time letting them do driver work from Plan 9 by "poking holes" in Xen to let Plan 9 at the real hardware. Xen supports this, we think, although we have not got it going yet ... I already like the situation thus far, as Plan 9 under Xen is a ton faster than Plan 9 under qemu. You have to see it to believe it; if anything, the Xen advantage is better than it used to be. I was surprised. to get to the point of poking holes in Xen, it turned out I need pcifront. For pcifront I need xenbus. for xenbus I need xenstore. There is xenstore support in Plan 9 already, but ... The xenstore sez: "incomplete". What would it take to complete it? conservative use of locks in the short term as a hack for really doing it right in the long term? The comment is this: * XXX This is incomplete - needs multiplexing of request/response protocol * and locking between driver and kernel-only xenstore_read/write interface. Should we set up queues for request/response? The locking seems simple enough, is there something I'm missing? ron
