Hi Dominique, On Tuesday 20 January 2009 23:58:35 Dominique Leuenberger wrote: > >>> On 1/20/2009 at 11:45 PM, Dmitry Torokhov <d...@vmware.com> wrote: > > > > - 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). >
We need to maintain the fall back mechanism for some time so users who might not be comfortable with using fuse or users who experience problems with it could have a way out until the issue is resolved. -- 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
