On Thursday, June 24, 2010 08:07:56 am Daniel P. Berrange wrote: > On Wed, Jun 23, 2010 at 10:08:06PM -0400, ian geiser wrote: > > Greetings, I have been working on adding the ability to expose local file > > systems to a remote instance of qemu. I have decided that since there is [snip] > > main use case is to share my local USB key with my VM. > > When you say you want to share the local USB key with the VM, I assume > you want the guest OS to access the files on the local client USB key, > rather than the remote virt host OS accessing the files ? If this is Yes, I was just providing a concrete use case. I want the client's OS to handle any access to the files on the USB key. This way the protocol can deal with files and directories instead of just forwarding the blocks to the host and letting it figure out the file system. The other advantage is that the client can expose single directories as a share, vs an entire file system. I guess the downside of this approach is that the host would not be able to do operations such as partitioning or formatting the client's exposed device, but I am not sure that is such a big deal at this point (Maybe after I tackle this mess I will be ready to handle something like USB redirection to accommodate that)
> true then I think that you might want to look at the plan9fs virtio driver > that was recently merged into QEMU, instead of vfat. The QEMU community > broadly considers vfat a gross hack with no future ahead of it, so I fear > you might find it hard to convince them to consider a VNC extension that Oh, good to know. I have to admit I was a little bit scared by the vvfat code, although I did find their approach intriguing. :) Naively I thought this would be a good starting point because pretty much every OS out there now supports FAT of some type, and it has enough features to get files moved around. Really I have been mirroring the API around the Linux FUSE api, and the limitations of VVFAT. > meshes with the vfat driver. Your RFB proposal does look like it could > mesh with the virtio plan9fs driver backends though. Currently that driver > has a backend impl that maps to the host filesystem, but it looks like it > would be possible to provide a driver that maps over to your VNC extension, > if you defined specs for a few more file operations. The hw/file-op-9p.h > file in QEMU defines all the ops needed for p9fs support. Again good to know. I will have to look at that more as I get the VNC commands implemented on qemu. Right now I have just been working on the client end. I want to have a concrete implementation so that I can make sure I am not missing obvious features in this spec. The big thing I think that I will need is the ability to have messages be asynchronous between the VNC server and the files driver. I may have more questions on the p9fs stuff, but that is another list :) > > The other approach to your use case would be to expose the local USB key > as a block device over VNC instead of a filesystem. Then, the guest OS > itself would be responsible for interpreting the filesystem operations > and the VNC extension would only need provide a generic random access, bulk > data transfer capability. The obvious downside of this idea though is that > if you wanted to allow write access, you could only give the USB key device > to one guest at a time, nor be able to access it from your local client OS > ie no concurrent write access. So I think your idea has merit, even though > its alot more work to implement. > Yes, I have to admit I do not know enough about qemu's guts to know if this is a breadbox or a breadtruck. Right now I live in a fantasy world that if I can get the server portion working someone will be inspired to help me with the rest :) -ian reinhart geiser ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
