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

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


This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
open-vm-tools-devel mailing list

Reply via email to