Hi everyone, While the guest kernel modules are open-sourced they are still not integrated with the mainline kernel and thus suffer from rapid kernel API changes that happen in mainline. Although getting some of the code upstream should be possible this can't be said about vmblock driver which exists mainly to work around the deficiency in gtk DnD protocol. It is highly unlikely that such driver will be accepted in mainline.
In the effort to shield ourselves from future API changes we would like to consider switching from vmblock kernel module to vmblock-fuse as our default blocking mechanism for DnD. FUSE is pretty stable by now and in addition to Linux there are also implementations for Solaris and FreeBSD; there were some issues with deadlocks with earlier versions of libfuse but I believe they have been resolved. What we need to change: - /proc/fs/vmblock/ can not be used with user space implementation, we need to move the mount point somewhere. I'd probably go with /var/run/vmblock or /var/run/vmblock-fuse. - DND code needs to try accessing new vmblock-fuse location before falling back to the legacy vmblock location. - Our startup scripts need to verify presence of FUSE module and compatible version of libfuse and load and mount vmblock-fuse instead of vmblock if FUSE is available. What do you think? -- Dmitry ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ open-vm-tools-devel mailing list open-vm-tools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel
