Re: Upstream QEMU based stubdom and rump kernel

[Martin Lucina <martin@lucina.net>]

pooka@rumpkernel.org said:
> etfs isn't a file system, e.g. it doesn't allow listing files or
> removing them, but it does give you complete control of what happens
> when data is read or written for /some/path.  But based on the other
> posts, sounds like it might be enough for what you need.
> 
> See:
> http://man.netbsd.org/cgi-bin/man-cgi?rump_etfs++NetBSD-current

They'd still need to implement the rumphyper/Mini-OS backend to get etfs to
talk over vchan to the dom0, right?

> That's not really a problem, though I do want to limit the amount of
> interface we claim to support with rump kernels.  For example, ISTR
> you mentioned on irc you'd like to use minios wait.h.  It would be
> better to use pthread synchronization instead of minios
> synchronization.  That way, if we do have a need to change the
> underlying threading in the future, you won't run into trouble.
> 
> So, we should just determine what is actually needed and expose
> those bits by default.

+1

Martin