From mboxrd@z Thu Jan 1 00:00:00 1970 From: Antti Kantee Subject: Re: Upstream QEMU based stubdom and rump kernel Date: Wed, 18 Mar 2015 13:22:53 +0000 Message-ID: <55097C2D.1030504@rumpkernel.org> References: <20150317142907.GD27314@zion.uk.xensource.com> <550850FB.2080406@rumpkernel.org> <20150318112208.GD17247@nodbug.moloch.sk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150318112208.GD17247@nodbug.moloch.sk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: wei.liu2@citrix.com, rumpkernel-users@freelists.org, xen-devel@lists.xen.org, Stefano Stabellini , Anthony PERARD , Ian Jackson , Ian Campbell List-Id: xen-devel@lists.xenproject.org On 18/03/15 11:22, Martin Lucina wrote: > 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? Strictly speaking, they'd have to implement the iov{read,write} hypercalls to do that. But, no, etfs doesn't do magic. IOW, they'd have to define what "host path" means. It occurred to me that I wrote that manpage, umm, 5 years ago when rump kernels ran only in userspace and "host path" was a better defined term. Pile that manpage on the neverending heap of documentation which broke while the code kept working.