On Thu, Jun 24, 2010 at 12:16:06PM -0400, ian geiser wrote: > On Thursday, June 24, 2010 08:07:56 am Daniel P. Berrange wrote: > > 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. > I did some looking at the 9p code. The only thing I am dubious about is the > need for symlinks. The underlying file system that the client exposes may or > may not support them. Think of our poor friend FAT who seems to make it onto > quite a few of our USB thumb drives and cameras... I think the same point > with setuid, mknod and chown arise too. Can those methods safely be stubbed > out and become no-ops? Or should there be an error returned similar to how > sharing a FAT volume via NFS works? I guess the argument comes down to if we > want the file system behavior to be consistent between client file systems, > or > if we want to give as many features as we can at the risk of certain client > shares behaving differently. > > I am also thinking about the way directories are iterated and files are > accessed. Currently I am mirroring my message sequence to fit more into the > FUSE api, but are there advantages to having an API like 9p? My vision is > that the client would expose these shares based on its configuration and > depending on the host's security policy it would allow them to be presented > either to the VM or some sort of userland application/driver in the case of > other VNC servers. > > Also not really a question for the protocol itself but the implementation in > qemu. On FUSE there is a notion of a thread that you can do things > asynchronously but expose a block in the main thread. Is there the same > notion in the 9p implementation? Or is that an exercise left to the > implementor? > > Sorry for all of the questions, but I would like to try to come up with a > message set that will make life easier for server and client implementations > on all platforms.
Good questions, but I'm afraid I'm not best positioned to answer them in details - probably worth sending your proposal directly to qemu-devel for additional feedback from the guys who know this filesystem code very well Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ------------------------------------------------------------------------------ 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
