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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).