Hi Dmitry >>> On 1/20/2009 at 11:45 PM, Dmitry Torokhov <d...@vmware.com> wrote: > While the guest kernel modules are open-sourced they are still not integrated >
sad but true ;) > 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. > Indeed, if it's just to 'hack up something else' chances for that part are really low I guess. > 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 I'm all in favor of a solution that works out in long-term. And fuse seems to become stronger and more stable with every release. So supporting it (and in case of lack of 'something' contributing it straight to fuse instead of hacking around) would probably be the very best way to go forward. The question would be: how long do you want to maintain both tracks? Why having the 'fall back' mechanism in? I think we could also just argue that from open-vm-tools-<random version> on, fuse is required dependency. Or at least have the code nicely factorized for DnD that it's easy removable (remove complexity whenever possible). Dominique ------------------------------------------------------------------------------ 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
