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 > 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