On 12.07.2010 16:41, Antti Kantee wrote: > It's not the same thing. Correct me if I misunderstood, but I thought > you want to port/adjust/whatever rumpuser to the xen hypercall interace. > Since the xen hypervisor interface, as opposed to a posix process > environment, is designed for hosting an OS, you can do lowlevel ops > as you'd expect to do them instead of having to think about high-level > semantic meaning.
My goal: take rumpuser, and see how it could be used in microkernel-like environment. Xen is my target (personal/free time work, just to make an initial approach to rumpuser), but other API might be possible (this part depends on external factors encountered at $DAYJOB). Though there are some points I am still unsure with, some of them being: - routing (the same way you pass message back and forth with puffs/pud); for Xen, this cannot be solved through the hypervisor API, you have to pull in Xen ring I/Os, and Xenstore, which acts as key:value storage facility so that domains can share information ("if you want to issue block requests for xbd0, contact domain 'foo'"). - drivers (how could it work with passthrough, what is attainable/what is not) This is motivated by the fact that I expect more and more systems embedded with hypervisors (think PS3, sun4v, z/VM). I am just curious how I could play with rump there. > ... well, at least in theory, since we can't measure it yet. Plus I'm > not ultrafamiliar with Xen (read: not familiar at all), so there might > be issues I don't foresee. And there always are. But business as usual: > only one way to find out ;) Heh, I am not at all familiar with your work, so... business as usual :) Cheers, -- Jean-Yves Migeon jeanyves.mig...@free.fr