Re: [Qemu-devel] Breaking out virtfs as a standalone server?
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.comforum_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
[Qemu-devel] Breaking out virtfs as a standalone server?
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.) 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? B) Break the 9p server out so it could be built as a standalone userspace program? Rob
Re: [Qemu-devel] Breaking out virtfs as a standalone server?
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; But for older protocols we have standalone servers like spfs/npfs. http://sourceforge.net/projects/npfs/ http://9p.cat-v.org/implementations 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. Not sure the latest though. http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTim4eZttAmaNQfOuM1h7cmLvO-osckHNunMvG7o%2B%40mail.gmail.comforum_name=v9fs-developer 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. 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. If there is enough interest I am sure these two are something we can look at as a community. - JV Rob
Re: [Qemu-devel] Breaking out virtfs as a standalone server?
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.comforum_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