Re: CVS commit: src/tests/net/icmp

[Antti Kantee <pooka%cs.hut.fi@localhost>]

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 ;)