[ open-vm-tools-Tracker-2523263 ] vmhgfs stops hibernation
Tracker item #2523263, was opened at 2009-01-20 11:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=989708aid=2523263group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dominique Leuenberger (dimstar) Assigned to: Nobody/Anonymous (nobody) Summary: vmhgfs stops hibernation Initial Comment: Bug has been copied from openSUSE bug tracker: https://bugzilla.novell.com/show_bug.cgi?id=461340 if vmhgfs kernel module is loaded, the system cannot be suspended anymore. (s2disk /dev/sda1 fails, leaving the call trace below). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=989708aid=2523263group_id=204462 -- 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
RFC: Move towards vmblock-fuse
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
