From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin Lucina Subject: Re: Upstream QEMU based stubdom and rump kernel Date: Wed, 18 Mar 2015 12:22:08 +0100 Message-ID: <20150318112208.GD17247@nodbug.moloch.sk> References: <20150317142907.GD27314@zion.uk.xensource.com> <550850FB.2080406@rumpkernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <550850FB.2080406@rumpkernel.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Antti Kantee Cc: wei.liu2@citrix.com, Ian Campbell , Stefano Stabellini , Ian Jackson , xen-devel@lists.xen.org, rumpkernel-users@freelists.org, Anthony PERARD List-Id: xen-devel@lists.xenproject.org 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