From: Venkateswararao Jujjuri <jvrao@linux.vnet.ibm.com>
To: Rob Landley <rob@landley.net>
Cc: Eric Van Hensbergen <ericvh@gmail.com>,
v9fs-developer@lists.sourceforge.net,
"Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Breaking out virtfs as a standalone server?
Date: Tue, 12 Apr 2011 07:34:20 -0700 [thread overview]
Message-ID: <4DA462EC.8010500@linux.vnet.ibm.com> (raw)
In-Reply-To: <4DA3E8A2.7010401@landley.net>
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
>
next prev parent reply other threads:[~2011-04-12 14:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-11 13:42 [Qemu-devel] Breaking out virtfs as a standalone server? Rob Landley
2011-04-11 20:28 ` Venkateswararao Jujjuri
2011-04-11 23:28 ` [Qemu-devel] [V9fs-developer] " Jim Garlick
2011-04-12 5:52 ` [Qemu-devel] " Rob Landley
2011-04-12 14:34 ` Venkateswararao Jujjuri [this message]
2011-04-12 17:24 ` [Qemu-devel] [V9fs-developer] " Rob Landley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DA462EC.8010500@linux.vnet.ibm.com \
--to=jvrao@linux.vnet.ibm.com \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=ericvh@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=rob@landley.net \
--cc=v9fs-developer@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.