On Mon Jul 12 2010 at 01:51:54 +0200, Jean-Yves Migeon wrote: > > Anyway, the solution as usual is to work the problem from both ends > > (improve the server methods and the kernel drivers) and perform a > > meet-in-the-middle attack at the sweet spot where nothing is lost and > > everything is gained. The cool thing about working on NetBSD is that > > we can actually do these things properly instead of bolting some hacks > > on top of a black-magic-box we're not allowed to touch. > > > > Although I'm not familiar with the Xen hypercall interface, I assume it > > to be infinitely more well-defined than unix process<->kernel interaction > > with no funny bits like fiddling about here and there just because the > > kernel can get away with it. > > Yes; however, note that the Xen hypercalls are not expected to be as > feature-rich as a POSIX process <> kernel interface. It is vastly > simpler, but it is also poorer (the complexity is left as an exercise to > the tasks above it). > > Anyway, you will face the exact same issue as yours with puffs and pud. > The Xen hypercalls are close to x86 semantics; at this layer, you have > lost most of the higher level semantic.
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. ... 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 ;)
