From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51236) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9efo-0003us-10 for qemu-devel@nongnu.org; Tue, 12 Apr 2011 10:34:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q9efi-0003XM-NW for qemu-devel@nongnu.org; Tue, 12 Apr 2011 10:34:31 -0400 Received: from e36.co.us.ibm.com ([32.97.110.154]:54924) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9efi-0003Wd-HA for qemu-devel@nongnu.org; Tue, 12 Apr 2011 10:34:26 -0400 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e36.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p3CESwZw017949 for ; Tue, 12 Apr 2011 08:28:58 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p3CEYOLb107220 for ; Tue, 12 Apr 2011 08:34:24 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p3CEYNHR010615 for ; Tue, 12 Apr 2011 08:34:24 -0600 Message-ID: <4DA462EC.8010500@linux.vnet.ibm.com> Date: Tue, 12 Apr 2011 07:34:20 -0700 From: Venkateswararao Jujjuri MIME-Version: 1.0 References: <4DA30529.1080501@landley.net> <4DA36481.3060205@linux.vnet.ibm.com> <4DA3E8A2.7010401@landley.net> In-Reply-To: <4DA3E8A2.7010401@landley.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Breaking out virtfs as a standalone server? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Rob Landley Cc: Eric Van Hensbergen , v9fs-developer@lists.sourceforge.net, "Aneesh Kumar K. V" , qemu-devel@nongnu.org On 04/11/2011 10:52 PM, Rob Landley wrote: > On 04/11/2011 03:28 PM, Venkateswararao Jujjuri wrote: >> On 04/11/2011 06:42 AM, Rob Landley wrote: >>> Right now, there's no decent userspace server for the 9p filesystem that >>> I can find. (In part because the 9P2000.L spec is an undocumented work >>> in progress.) >> This statement is true for 9P2000.L protocol; > According to my research on the topic, anyway: > > http://landley.livejournal.com/48698.html You wrote " And at the moment write support seems to be broken for me. But I was able to mount a directory from the host system and cat a file, which is progress." Can you please explain where it is broken. IT should be working good. - JV >> But for older protocols we have standalone servers like spfs/npfs. >> http://sourceforge.net/projects/npfs/ > This would be the one that has no documentation or web page, builds > without ./configure, and has no way to specify which directory to export > but apparently can ONLY export / on the host? > >> http://9p.cat-v.org/implementations > I looked at those. Several are unfinished libraries, some also only > export / and treat the whole "restrict what you're exporting to a > subdir" problem as inherently unsolvable (readlink -f), the main one > everybody seems to test with is the Inferno equivalent of usermode > Linux, there's a python server that refuses to run without some third > party encryption/authentication library that it never OCCURRED to their > developers you might want t disable... > > I also tracked down more like http://code.google.com/p/diod/ (and > emailed its author for a while: that project is stalled due to his > desire to rewrite large chunks of it, and a lack of time). > > I also subscribed to v9fs-users, which is not the world's highest > traffic list: > > http://sourceforge.net/mailarchive/forum.php?forum_name=v9fs-users > >>> The only up-to-date server seems to be virtfs in qemu, which has no TCP >>> transport layer. >>> >>> Are there any plans to: >>> >>> A) Add a TCP transport layer so we can test with something we can >>> intercept/examine/log/redirect with netcat and such? >> No plans as of now; I know folks in the Latchesar Ionkov attempted char >> dev transport. > NFS works over TCP. Samba works over TCP. But not p9. Is there some > reason to go out of the way to avoid it? > >> Not sure the latest though. >> >> http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTim4eZttAmaNQfOuM1h7cmLvO-osckHNunMvG7o%2B%40mail.gmail.com&forum_name=v9fs-developer > Ah, if I want information about userspace servers I should subscribe to > v9fs-developer instead of v9fs-user, because it has no users yet. Got it. > >>> B) Break the 9p server out so it could be built as a standalone >>> userspace program? >> No plans yet..and I think this is a bigger discussion. > If this filesystem is to become more than an academic exercise, it needs > a server that can export a specific directory. > >> Being part of QEMU brings few implicit advantages like simplicity in >> sharing, security >> and performance advantage. I think taking it out can have its own merits. > I wasn't suggesting removing it from QEMU. Having it in QEMU is great, > the code is written and works, it's useful as-is, and half the _idea_ of > this is that it's simpler than samba or NFS (which is damning with faint > praise, I know). > > In theory, all the actual protocol encoding and decoding (and doing the > read/write/stat stuff on the host) is a single C file, correct? Right > now there isn't any reference implementation of that server-side code, > but there is a working example of it. Virtfs is a working example, just > not hooked up to a particularly useful transport. (If it had a TCP > transport I could route it back out through a tap interface or -redir > port and use qemu as a test server... but it doesn't. As far as I can > tell, virtio is intentionally the _least_ flexible mechanism for that > sort of thing. Although maybe there's docs on this and I've just missed > them...) > > Rob >