open-vm-tools-devel — List for open-vm-tools developer discussions.

[ open-vm-tools-Tracker-2298353 ] vmware-user does not autostart

[SourceForge.net <no...@so...>]

Tracker item #2298353, was opened at 2008-11-16 04:46
Message generated for change (Comment added) made by mvanzin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2298353&group_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: vmware-user
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: lucatrv (lucatrv)
Assigned to: Nobody/Anonymous (nobody)
Summary: vmware-user does not autostart

Initial Comment:
Ubuntu Intrepid 8.10
Although the vmware-user.desktop link is present in /etc/xdg/autostart , vmware-user does not start automatically at boot. So copy/past doesn't work.

This has a very quick fix: add the line line "Type=Application" in the file  vmware-user.desktop

$ cat vmware-user.desktop 
[Desktop Entry]
Type=Application
Encoding=UTF-8
Exec=vmware-user-suid-wrapper
Name=VMware User Agent
X-KDE-autostart-phase=1
NoDisplay=true

Now vmware-user starts at boot so copy/paste works.

Please add this very quick fix to the next release...

Thanks

PS. to improve your documentation page (http://open-vm-tools.wiki.sourceforge.net/Packaging) I think you should add under the vmhgfs paragraph (after the fstab description) a phrase telling that if one doesn't want that updatedb indexes all the shared folder it is necessary to add "vmhgfs" in the file /etc/updatedb.conf after "PRUNEFS=". In fact, this was automatically done by the old perl installer.


----------------------------------------------------------------------

Comment By: Marcelo Vanzin (mvanzin)
Date: 2008-11-18 18:24

Message:
This is fixed in the latest code refresh (2008.11.18).

----------------------------------------------------------------------

Comment By: Syd Logan (slogan621)
Date: 2008-11-17 00:07

Message:
Thanks, we ran into that fix a week or so ago and the fix you described
should be in an upcoming release.

----------------------------------------------------------------------

Comment By: lucatrv (lucatrv)
Date: 2008-11-16 13:50

Message:
Ops, sorry, I didn't notice it was mentioned already. So you can ignore the
last "PS" part of my post.

----------------------------------------------------------------------

Comment By: Ragavan S (ragavan_s)
Date: 2008-11-16 13:20

Message:
Thanks for submitting this. With regards to the documentation suggestion, I
think we already mention this in the vmhgfs section:

"We typically exclude vmhgfs from the locate database as crawling the
Shared Folders is time consuming. To do this, add "vmhgfs" to PRUNEFS
within updatedb's configuration file, typically found in
/etc/updatedb.conf"

Is this what you were suggesting or something else?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2298353&group_id=204462

RE: [open-vm-tools-devel] Getting the kernel modules into Linux mainline

[Chris M. <ma...@ch...>]

On Tue, 2008-11-18 at 12:57 -0800, Adar Dembo wrote:
> > Just for completeness, here's the updated patch for vmblock, which I've
> > run through the vmblocktest tool that Adar posted.  Seems a shame not to
> > post it somewhere so you guys might as well have it!
> > 
> > It's checkpatch and sparse clean, and applies against 2.6.27.
> 
> Thanks, Chris. When the vmblock-fuse code gets added to the open-vm-tools we can bring this patch out and talk about what happens next.
> 
> Just out of curiosity, how long did this cleanup effort take? We're trying to gauge how much work is involved in preparing a module for inclusion upstream, and since you're the first to try, your feedback would be appreciated.
> 

Probably took me longer than somebody who was already familiar with the
code; I systematically went through each file in turn, doing the easy
stuff like whitespace first and committing after each one, using
checkpatch.pl as a guide to how much work was left to complete (i.e. the
number of lines with warnings / total LOC). I had a script to run
checkpatch, compile with sparse, compare object code and print out a
"percent done" as an incentive! Took about 3 weeks (doing an hour or two
per day) to get to the state of the original patch, where it was clean
of warnings but still looked a bit "alien" wrt other kernel code.

By that time I was familiar enough with the code that I could start with
an empty file and (using similar modules like romfs as a guide) build it
up from the bottom with linux kernel-style identifiers and paste only
the bare minimum code. That was pretty quick, a few days maybe.

Since then I've just had to diff -rup the vmblock directory in the
subsequent open-vm-tools releases to grab the latest relevant stuff
which was pretty straightforward, and probably not a huge amount of
ongoing maintenance effort.

If I was going to do it again, if the source looks like it needs
substantial rework, then there isn't much value in hundreds of
individual commits; I think I'd jump straight into creating the module
from scratch and pasting the relevant code snippets directly.  Some
documentation and test harnesses would be really really useful here,
because then you could be a bit less paranoid about diffing object code
at each stage.

cheers
Chris

RE: [open-vm-tools-devel] Getting the kernel modules into Linux mainline

[Adar D. <ad...@vm...>]

> Just for completeness, here's the updated patch for vmblock, which I've
> run through the vmblocktest tool that Adar posted.  Seems a shame not to
> post it somewhere so you guys might as well have it!
> 
> It's checkpatch and sparse clean, and applies against 2.6.27.

Thanks, Chris. When the vmblock-fuse code gets added to the open-vm-tools we can bring this patch out and talk about what happens next.

Just out of curiosity, how long did this cleanup effort take? We're trying to gauge how much work is involved in preparing a module for inclusion upstream, and since you're the first to try, your feedback would be appreciated.

Re: [open-vm-tools-devel] Getting the kernel modules into Linux mainline

[Chris M. <ma...@ch...>]

Just for completeness, here's the updated patch for vmblock, which I've
run through the vmblocktest tool that Adar posted.  Seems a shame not to
post it somewhere so you guys might as well have it!

It's checkpatch and sparse clean, and applies against 2.6.27.

--
From: Chris Malley <ma...@ch...>
Subject: [PATCH] fs: add support for VMware vmblock "blocking" filesystem

This is a pseudo filesystem used by VMware tools to enforce safe
drag-and-drop / copy-and-paste functionality between host and guest.

Adapted from the open-vm-tools project, version 2008.10.10

Signed-off-by: Chris Malley <ma...@ch...>
---
 Documentation/filesystems/vmblock.txt |   68 ++
 fs/Kconfig                            |   21 +
 fs/Makefile                           |    1 +
 fs/vmblock/Makefile                   |    7 +
 fs/vmblock/vmblock_fs.c               | 1159 +++++++++++++++++++++++++++++++++
 include/linux/Kbuild                  |    1 +
 include/linux/vmblock.h               |   49 ++
 7 files changed, 1305 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/filesystems/vmblock.txt
 create mode 100644 fs/vmblock/Makefile
 create mode 100644 fs/vmblock/vmblock_fs.c
 create mode 100644 include/linux/vmblock.h

diff --git a/Documentation/filesystems/vmblock.txt b/Documentation/filesystems/vmblock.txt
new file mode 100644
index 0000000..ff5f98b
--- /dev/null
+++ b/Documentation/filesystems/vmblock.txt
@@ -0,0 +1,68 @@
+VMware Blocking Filesystem driver
+---------------------------------
+
+PURPOSE
+
+VMware have created a driver to enable safe drag and drop operations
+between host and guest, by implementing a pseudo "blocking" filesystem.
+
+The idea is that files can be copied via a temporary directory, but the target
+should not be able to access the file until the copy has finished.  This is
+accomplished by mounting a "view" of the directory, containing only symlinks
+to the real files, and a special control file.  Before copying, a "block"
+command is issued to the control file along with the filename.  Now any attempt
+to access the file via the view will block until a "release" command is issued
+(presumably after the source is happy that the copy has completed).
+
+
+TESTING
+
+1. Make a directory on the guest to store the files (/tmp/VMwareDnD by default):
+	# mkdir /tmp/VMwareDnD
+	# chmod 1777 /tmp/VMwareDnD
+	# echo "a test file" > /tmp/VMwareDnD/foo
+
+2. Load the vmblock module:
+	# modprobe vmblock
+	# ls -p /proc/fs/vmblock
+	dev  mountPoint/
+
+3. Mount the blocking filesystem:
+	# mount -t vmblock none /proc/fs/vmblock/mountPoint
+	# ls -l /proc/fs/vmblock/mountPoint
+	foo -> /tmp/VMwareDnD/foo
+
+4. To place a block on a file (see listing [1] below):
+	# cat /proc/fs/vmblock/mountPoint/foo
+	a test file
+	# addblock_wait10 /tmp/VMwareDnD/foo &
+	# cat /proc/fs/vmblock/mountPoint/foo
+	<ten seconds later....>
+	a test file
+
+
+EXAMPLE USERSPACE CODE
+
+/* addblock_wait10.c */
+#include <linux/limits.h>
+#include <linux/vmblock.h>
+#include <string.h>
+#include <fcntl.h>
+
+int main(int argc, char *argv[]) {
+	char buf[PATH_MAX];
+	
+	int fd = open(VMBLOCK_DEVICE, VMBLOCK_DEVICE_MODE);
+
+	strncpy(buf, argv[1], PATH_MAX);
+	/*
+	 * The size of the write dictates the type of command.
+	 * For example, VMBLOCK_ADD_FILEBLOCK is 98 bytes.
+	 * However the module will actually read PATH_MAX bytes!
+	 */
+	write(fd, buf, VMBLOCK_ADD_FILEBLOCK); /* should return 0 */
+	sleep(10); /* file is now blocked for 10 secs */
+
+	close(fd); /* block is released */
+}
+/* end of addblock_wait10.c */
diff --git a/fs/Kconfig b/fs/Kconfig
index abccb5d..cbf4837 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -979,6 +979,27 @@ config CONFIGFS_FS
 	  Both sysfs and configfs can and should exist together on the
 	  same system. One is not a replacement for the other.
 
+config VMBLOCK_FS
+	tristate "VMware blocking filesystem (EXPERIMENTAL)"
+	depends on EXPERIMENTAL
+	default n
+	help
+	  Select this option if you plan to run VMware and you want
+	  to enable drag-and-drop and copy-and-paste operations between
+	  host and guest.
+
+	  See <file:Documentation/filesystems/vmblock.txt> for details.
+
+	  If you have no intention of running VMware, say N.
+
+config VMBLOCK_DEBUG
+	bool "VMware blocking filesystem debugging"
+	default n
+	depends on VMBLOCK_FS
+	help
+	  Enable vmblock debugging features such as the facility to list
+	  all the current file blocks.
+
 endmenu
 
 menu "Miscellaneous filesystems"
diff --git a/fs/vmblock/Makefile b/fs/vmblock/Makefile
new file mode 100644
index 0000000..5dfb4db
--- /dev/null
+++ b/fs/vmblock/Makefile
@@ -0,0 +1,7 @@
+#
+# Makefile for the linux vmblock filesystem routines.
+#
+
+obj-$(CONFIG_VMBLOCK_FS) += vmblock.o
+
+vmblock-objs := vmblock_fs.o
diff --git a/fs/vmblock/vmblock_fs.c b/fs/vmblock/vmblock_fs.c
new file mode 100644
index 0000000..129d25a
--- /dev/null
+++ b/fs/vmblock/vmblock_fs.c
@@ -0,0 +1,1159 @@
+/*
+ * Copyright (C) 2006 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+/*
+ * Rework for inclusion into Linux mainline
+ * Copyright (C) 2008, Chris Malley <ma...@ch...>
+ */
+
+#include <linux/fs.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/namei.h>
+#include <linux/module.h>
+#include <linux/proc_fs.h>
+#include <linux/sched.h>
+#include <linux/slab.h>
+#include <linux/statfs.h>
+#include <linux/string.h>
+#include <linux/vmblock.h>
+
+#define VMBLOCK_FS_NAME		"vmblock"
+#define VMBLOCK_ROOT_INO	1
+#define VMBLOCK_BLOCKSIZE	1024
+#define VMBLOCK_SUPER_MAGIC	0xabababab
+#define VMBLOCK_UNKNOWN_BLOCKER	NULL
+
+#define VMBLOCK_ERROR(fmt, args...)  \
+	pr_err("vmblock:%s:%u " fmt "\n", __func__, __LINE__, ##args)
+#define VMBLOCK_WARNING(fmt, args...)  \
+	pr_warning("vmblock:%s:%u " fmt "\n", __func__, __LINE__, ##args)
+#define VMBLOCK_INFO(fmt, args...)  \
+	pr_info("vmblock:%s:%u " fmt "\n", __func__, __LINE__, ##args)
+#define VMBLOCK_DEBUG(fmt, args...)  \
+	pr_debug("vmblock:%s:%u " fmt "\n", __func__, __LINE__, ##args)
+
+
+struct vmb_inode_info {
+	char		name[PATH_MAX];
+	size_t		name_len;
+	struct dentry	*actual_dentry;
+	struct inode	inode;
+};
+
+struct vmb_blocking_info {
+	struct list_head links;
+	atomic_t refcount;
+	struct file *blocker;
+	struct completion completion;
+	char filename[PATH_MAX];
+};
+
+struct vmb_filldir_info {
+	filldir_t filldir;
+	void *dirent;
+};
+
+static struct kmem_cache *vmb_inode_info_cache;
+static char *root = "/tmp/VMwareDnD";
+module_param(root, charp, 0600);
+MODULE_PARM_DESC(root, "The directory the file system redirects to");
+
+/*
+ * vmb_blocking_wait_on_file() is the only blocking function called from the
+ * filesystem section, so declare it here.
+ */
+static int vmb_blocking_wait_on_file(const char *filename);
+
+/*
+ * Filesystem section
+ *
+ * The following functions implement the filesystem operations necessary to
+ * present a custom view of the underlying directory.
+ *
+ */
+
+/* Filesystem utility functions */
+
+static inline struct vmb_inode_info *vmb_inode_to_iinfo(
+	struct inode *inode)
+{
+	return container_of(inode, struct vmb_inode_info, inode);
+}
+
+static inline struct dentry *vmb_inode_to_actual_dentry(
+	struct inode *inode)
+{
+	return vmb_inode_to_iinfo(inode)->actual_dentry;
+}
+
+static inline struct inode *vmb_inode_to_actual_inode(
+	struct inode *inode)
+{
+	return vmb_inode_to_actual_dentry(inode)->d_inode;
+}
+
+static int vmb_make_full_name(struct inode *dir,
+	struct dentry *dentry, char *buf_out, size_t buf_out_size)
+{
+	struct vmb_inode_info *dir_iinfo;
+	int ret;
+	int size_req;
+	const char *sep;
+	const char *dirname;
+	const char *filename;
+
+	BUG_ON(!buf_out);
+
+	/*
+	 * If dir is supplied, contruct the full path of the actual file,
+	 * otherwise it's the root directory.
+	 */
+	if (dir) {
+		BUG_ON(!dentry);
+
+		if (!dentry->d_name.name) {
+			VMBLOCK_ERROR("dentry name is empty");
+			ret = -EINVAL;
+			goto out_name;
+		}
+
+		dir_iinfo = vmb_inode_to_iinfo(dir);
+
+		dirname = dir_iinfo->name;
+		filename = dentry->d_name.name;
+	} else {
+		dirname = root;
+		filename = "";
+	}
+
+	if ((strlen(dirname) <= 1) || (strlen(filename) == 0))
+		sep = "";
+	else
+		sep = "/";
+
+	size_req = strlen(dirname) + strlen(sep) + strlen(filename) + 1;
+
+	if (size_req > buf_out_size) {
+		VMBLOCK_ERROR("path too long");
+		ret = -ENAMETOOLONG;
+		goto out_name;
+	}
+
+	snprintf(buf_out, buf_out_size, "%s%s%s", dirname, sep, filename);
+	ret = 0;
+
+out_name:
+	return ret;
+}
+
+static struct inode *vmb_get_inode(struct super_block *sb,
+	struct inode *dir, struct dentry *dentry, ino_t ino)
+{
+	struct vmb_inode_info *iinfo;
+	struct nameidata actual_nd;
+	struct inode *inode;
+
+	BUG_ON(ino < VMBLOCK_ROOT_INO);
+
+	inode = iget_locked(sb, ino);
+
+	if (!inode)
+		goto out_inode;
+
+	iinfo = vmb_inode_to_iinfo(inode);
+
+	if (inode->i_state & I_NEW) {
+		iinfo->name[0] = '\0';
+		iinfo->name_len = 0;
+		iinfo->actual_dentry = NULL;
+		unlock_new_inode(inode);
+	}
+
+	if (vmb_make_full_name(dir, dentry, iinfo->name,
+						sizeof iinfo->name) < 0) {
+		VMBLOCK_ERROR("could not make full name");
+		iput(inode);
+		goto out_inode;
+	}
+
+	if (path_lookup(iinfo->name, 0, &actual_nd)) {
+		/*
+		 * This file does not exist, so we create an inode that doesn't
+		 * know about its underlying file.  Operations that create files
+		 * and directories need an inode to operate on even if there is
+		 * no actual file yet.
+		 */
+		iinfo->actual_dentry = NULL;
+	} else {
+		iinfo->actual_dentry = actual_nd.path.dentry;
+		path_put(&actual_nd.path);
+	}
+
+out_inode:
+	return inode;
+}
+
+/* Link dentry operations */
+
+static int vmb_dentry_revalidate(struct dentry *dentry,
+	struct nameidata *nd)
+{
+	struct vmb_inode_info *iinfo;
+	struct nameidata actual_nd;
+	struct dentry *actual_dentry;
+	int ret;
+
+	if (!dentry) {
+		VMBLOCK_WARNING("invalid args from kernel");
+		return 0;
+	}
+
+	/*
+	 * If a dentry does not have an inode associated with it then
+	 * we are dealing with a negative dentry. Always invalidate a negative
+	 * dentry which will cause a fresh lookup.
+	 */
+	if (!dentry->d_inode)
+		return 0;
+
+
+	iinfo = vmb_inode_to_iinfo(dentry->d_inode);
+	if (!iinfo) {
+		VMBLOCK_WARNING("dentry has no fs-specific data");
+		return 0;
+	}
+
+	/* Block if there is a pending block on this file */
+	vmb_blocking_wait_on_file(iinfo->name);
+
+	/*
+	 * If the actual dentry has a revalidate function, we'll let it figure
+	 * out whether the dentry is still valid. If not, do a path lookup to
+	 * ensure that the file still exists.
+	 */
+	actual_dentry = iinfo->actual_dentry;
+
+	if (actual_dentry &&
+		actual_dentry->d_op &&
+		actual_dentry->d_op->d_revalidate) {
+			return actual_dentry->d_op->d_revalidate(actual_dentry,
+				nd);
+	}
+
+	if (path_lookup(iinfo->name, 0, &actual_nd)) {
+		VMBLOCK_INFO("[%s] no longer exists",	iinfo->name);
+		return 0;
+	}
+	ret = actual_nd.path.dentry &&
+		actual_nd.path.dentry->d_inode;
+	path_put(&actual_nd.path);
+
+	VMBLOCK_DEBUG("[%s] %s revalidated", iinfo->name, ret ? "" : "not");
+	return ret;
+}
+
+static struct dentry_operations vmb_link_dentry_ops = {
+	.d_revalidate = vmb_dentry_revalidate,
+};
+
+/* Link inode operations */
+
+static int vmb_readlink(struct dentry *dentry, char __user *buffer,
+	int buflen)
+{
+	struct vmb_inode_info *iinfo;
+
+	if (!dentry || !buffer) {
+		VMBLOCK_WARNING("invalid args from kernel");
+		return -EINVAL;
+	}
+
+	iinfo = vmb_inode_to_iinfo(dentry->d_inode);
+	if (!iinfo)
+		return -EINVAL;
+
+	return vfs_readlink(dentry, buffer, buflen, iinfo->name);
+}
+
+static void *vmb_follow_link(struct dentry *dentry, struct nameidata *nd)
+{
+	int ret;
+	struct vmb_inode_info *iinfo;
+
+	if (!dentry) {
+		VMBLOCK_WARNING("invalid args from kernel");
+		ret = -EINVAL;
+		goto out_link;
+	}
+
+	iinfo = vmb_inode_to_iinfo(dentry->d_inode);
+	if (!iinfo) {
+		ret = -EINVAL;
+		goto out_link;
+	}
+
+	ret = vfs_follow_link(nd, iinfo->name);
+
+out_link:
+	return ERR_PTR(ret);
+}
+
+static const struct inode_operations vmb_link_inode_ops = {
+	.readlink	= vmb_readlink,
+	.follow_link	= vmb_follow_link,
+};
+
+/* Root inode operations */
+
+static ino_t vmb_get_next_ino(void)
+{
+	static DEFINE_SPINLOCK(vmb_ino_lock);
+	static ino_t next_ino = VMBLOCK_ROOT_INO + 1;
+	ino_t ret;
+
+	spin_lock(&vmb_ino_lock);
+	ret = next_ino++;
+	spin_unlock(&vmb_ino_lock);
+
+	return ret;
+}
+
+static struct dentry *vmb_lookup(struct inode *dir,	struct dentry *dentry,
+	struct nameidata *nd)
+{
+	char *filename;
+	struct inode *inode;
+	int ret;
+
+	if (!dir || !dentry) {
+		VMBLOCK_WARNING("invalid args from kernel");
+		return ERR_PTR(-EINVAL);
+	}
+
+	/*
+	 * The kernel should only pass us our own inodes, but check just to be
+	 * safe.
+	 */
+	if (!vmb_inode_to_iinfo(dir)) {
+		VMBLOCK_WARNING("invalid inode provided");
+		return ERR_PTR(-EINVAL);
+	}
+
+	/* Get a slab from the kernel's names_cache of PATH_MAX-sized buffers */
+	filename = __getname();
+	if (!filename) {
+		VMBLOCK_WARNING("unable to obtain memory for filename");
+		return ERR_PTR(-ENOMEM);
+	}
+
+	ret = vmb_make_full_name(dir, dentry, filename, PATH_MAX);
+	if (ret < 0) {
+		VMBLOCK_WARNING("could not construct full name");
+		__putname(filename);
+		return ERR_PTR(ret);
+	}
+
+	/* Block if there is a pending block on this file */
+	vmb_blocking_wait_on_file(filename);
+	__putname(filename);
+
+	inode = vmb_get_inode(dir->i_sb, dir, dentry,
+						vmb_get_next_ino());
+	if (!inode) {
+		VMBLOCK_WARNING("failed to get inode");
+		return ERR_PTR(-ENOMEM);
+	}
+
+	dentry->d_op = &vmb_link_dentry_ops;
+	dentry->d_time = jiffies;
+
+	/*
+	 * If the actual file's dentry doesn't have an inode, it means the file
+	 * we are redirecting to doesn't exist.  Give back the inode that was
+	 * created for this and add a NULL dentry->inode entry in the dcache.
+	 * (The NULL entry is added so ops to create files/directories are
+	 * invoked by VFS.)
+	 */
+	if (!vmb_inode_to_actual_dentry(inode) ||
+				!vmb_inode_to_actual_inode(inode)) {
+		iput(inode);
+		d_add(dentry, NULL);
+		return NULL;
+	}
+
+	inode->i_mode = S_IFLNK | S_IRWXUGO;
+	inode->i_size = vmb_inode_to_iinfo(inode)->name_len;
+	inode->i_version = 1;
+	inode->i_atime = inode->i_mtime = inode->i_ctime = CURRENT_TIME;
+	inode->i_uid = inode->i_gid = 0;
+	inode->i_op = &vmb_link_inode_ops;
+
+	d_add(dentry, inode);
+	return NULL;
+}
+
+static const struct inode_operations vmb_root_inode_ops = {
+	.lookup	= vmb_lookup,
+};
+
+/* Root file operations */
+
+static int vmb_filldir(void *buf,
+	const char *name,
+	int namelen,
+	loff_t offset,
+	u64 ino,
+	unsigned int d_type)
+{
+	struct vmb_filldir_info *info = (struct vmb_filldir_info *)buf;
+
+	/* Specify DT_LNK regardless */
+	return info->filldir(info->dirent, name, namelen, offset, ino, DT_LNK);
+}
+
+static int vmb_readdir(struct file *file, void *dirent, filldir_t filldir)
+{
+	int ret;
+	struct vmb_filldir_info info;
+	struct file *actual_file;
+
+	if (!file) {
+		VMBLOCK_WARNING("invalid args from kernel");
+		return -EINVAL;
+	}
+
+	actual_file = file->private_data;
+	if (!actual_file) {
+		VMBLOCK_WARNING("no actual file found");
+		return -EINVAL;
+	}
+
+	info.filldir = filldir;
+	info.dirent = dirent;
+
+	actual_file->f_pos = file->f_pos;
+	ret = vfs_readdir(actual_file, vmb_filldir, &info);
+	file->f_pos = actual_file->f_pos;
+
+	return ret;
+}
+
+static int vmb_open(struct inode *inode, struct file *file)
+{
+	struct vmb_inode_info *iinfo;
+	struct file *actual_file;
+
+	if (!inode || !file || !vmb_inode_to_iinfo(inode)) {
+		VMBLOCK_WARNING("invalid args from kernel");
+		return -EINVAL;
+	}
+
+	iinfo = vmb_inode_to_iinfo(inode);
+
+	/*
+	 * Get an open file for the directory we are redirecting to.  This
+	 * ensures we can gracefully handle cases where that directory is
+	 * removed after we are mounted.
+	 */
+	actual_file = filp_open(iinfo->name, file->f_flags, file->f_flags);
+	if (IS_ERR(actual_file)) {
+		VMBLOCK_WARNING("could not open file [%s]", iinfo->name);
+		file->private_data = NULL;
+		return PTR_ERR(actual_file);
+	}
+
+	/*
+	 * If the file opened is the same as the one retrieved for the file
+	 * then we shouldn't allow the open to happen.  This can only occur if
+	 * the redirected root directory specified at mount time is the same as
+	 * where the mount is placed.  Later in vmb_readdir() we'd call
+	 * vfs_readdir() and that would try to acquire the inode's semaphore;
+	 * if the two inodes are the same we'll deadlock.
+	 */
+	if (actual_file->f_dentry && inode == actual_file->f_dentry->d_inode) {
+		VMBLOCK_WARNING("identical inode encountered, "
+				"open cannot succeed");
+		if (filp_close(actual_file, current->files) < 0)
+			VMBLOCK_WARNING("unable to close opened file");
+		return -EINVAL;
+	}
+
+	file->private_data = actual_file;
+	return 0;
+}
+
+static int vmb_release(struct inode *inode, struct file *file)
+{
+	int ret;
+	struct file *actual_file;
+
+	if (!inode || !file) {
+		VMBLOCK_WARNING("invalid args from kernel");
+		return -EINVAL;
+	}
+
+	actual_file = file->private_data;
+	if (!actual_file) {
+		VMBLOCK_WARNING("no actual file found");
+		return -EINVAL;
+	}
+
+	ret = filp_close(actual_file, current->files);
+
+	return ret;
+}
+
+static const struct file_operations vmb_root_file_ops = {
+	.readdir	= vmb_readdir,
+	.open		= vmb_open,
+	.release	= vmb_release,
+};
+
+/* Super block operations */
+
+static struct inode *vmb_alloc_inode(struct super_block *sb)
+{
+	struct vmb_inode_info *iinfo;
+
+	iinfo = kmem_cache_alloc(vmb_inode_info_cache, GFP_KERNEL);
+	if (!iinfo) {
+		VMBLOCK_ERROR("could not allocate inode info");
+		return NULL;
+	}
+
+	return &iinfo->inode;
+}
+
+static void vmb_destroy_inode(struct inode *inode)
+{
+	kmem_cache_free(vmb_inode_info_cache, vmb_inode_to_iinfo(inode));
+}
+
+static int vmb_statfs(struct dentry *dentry, struct kstatfs *stat)
+{
+	if (!stat)
+		return -EINVAL;
+
+	stat->f_type = VMBLOCK_SUPER_MAGIC;
+	stat->f_bsize = 0;
+	stat->f_namelen = NAME_MAX;
+	stat->f_blocks = 0;
+	stat->f_bfree = 0;
+	stat->f_bavail = 0;
+
+	return 0;
+}
+
+static const struct super_operations vmb_super_ops = {
+	.alloc_inode	= vmb_alloc_inode,
+	.destroy_inode	= vmb_destroy_inode,
+	.statfs		= vmb_statfs,
+};
+
+/* File system operations */
+
+static int vmb_fill_super(struct super_block *sb, void *data, int silent)
+{
+	struct inode *root_inode;
+	struct dentry *root_dentry;
+
+	sb->s_magic = VMBLOCK_SUPER_MAGIC;
+	sb->s_blocksize = VMBLOCK_BLOCKSIZE;
+	sb->s_op = &vmb_super_ops;
+
+	root_inode = vmb_get_inode(sb, NULL, NULL, VMBLOCK_ROOT_INO);
+
+	if (!root_inode)
+		return -EINVAL;
+
+	if (!vmb_inode_to_iinfo(root_inode) ||
+		!vmb_inode_to_actual_dentry(root_inode) ||
+		!vmb_inode_to_actual_inode(root_inode) ||
+		!S_ISDIR(vmb_inode_to_actual_inode(root_inode)->i_mode)) {
+		iput(root_inode);
+		return -EINVAL;
+	}
+
+	root_dentry = d_alloc_root(root_inode);
+	if (!root_dentry) {
+		iput(root_inode);
+		return -ENOMEM;
+	}
+	sb->s_root = root_dentry;
+
+	root_inode->i_op = &vmb_root_inode_ops;
+	root_inode->i_fop = &vmb_root_file_ops;
+	root_inode->i_mode = S_IFDIR | S_IRUGO | S_IXUGO;
+
+	VMBLOCK_INFO("%s: file system mounted", VMBLOCK_FS_NAME);
+
+	return 0;
+}
+
+static int vmb_get_sb(struct file_system_type *fs_type,
+	int flags, const char *dev_name, void *data, struct vfsmount *mnt)
+{
+	return get_sb_nodev(fs_type, flags, data, vmb_fill_super, mnt);
+
+}
+
+static struct file_system_type vmb_fs_type = {
+	.owner		= THIS_MODULE,
+	.name		= VMBLOCK_FS_NAME,
+	.get_sb		= vmb_get_sb,
+	.kill_sb	= kill_anon_super,
+};
+
+static void vmb_inode_info_cache_ctor(void *slab_elem)
+{
+	struct vmb_inode_info *iinfo = slab_elem;
+
+	inode_init_once(&iinfo->inode);
+}
+
+static int __init vmb_fs_init(const char *fsroot)
+{
+	int err;
+
+	if (!fsroot) {
+		VMBLOCK_ERROR("no root specified (missing module param?)");
+		err = -EINVAL;
+		goto out_fs;
+	}
+
+	vmb_inode_info_cache = kmem_cache_create(
+				"vmb_inode_info_cache",
+				sizeof(struct vmb_inode_info), 0,
+				SLAB_HWCACHE_ALIGN,
+				vmb_inode_info_cache_ctor);
+
+	if (!vmb_inode_info_cache) {
+		VMBLOCK_ERROR("could not initialize inode cache");
+		err = -ENOMEM;
+		goto out_fs;
+	}
+
+	err = register_filesystem(&vmb_fs_type);
+	if (err) {
+		VMBLOCK_ERROR("could not register filesystem");
+		kmem_cache_destroy(vmb_inode_info_cache);
+		goto out_fs;
+	}
+
+out_fs:
+	return err;
+}
+
+static void __exit vmb_fs_cleanup(void)
+{
+	unregister_filesystem(&vmb_fs_type);
+
+	kmem_cache_destroy(vmb_inode_info_cache);
+}
+
+/*
+ * Blocking section
+ *
+ * The following functions implement the blocking functionality.
+ */
+
+static LIST_HEAD(vmb_blocked_files);
+static rwlock_t vmb_blocked_files_lock;
+static struct kmem_cache *vmb_blocking_info_cache;
+
+static int vmb_blocking_init(void)
+{
+	BUG_ON(vmb_blocking_info_cache);
+
+	vmb_blocking_info_cache = kmem_cache_create("vmb_blocking_info_cache",
+					sizeof(struct vmb_blocking_info), 0,
+					SLAB_HWCACHE_ALIGN, NULL);
+	if (!vmb_blocking_info_cache)
+		return -ENOMEM;
+
+	INIT_LIST_HEAD(&vmb_blocked_files);
+	rwlock_init(&vmb_blocked_files_lock);
+
+	return 0;
+}
+
+static void vmb_blocking_cleanup(void)
+{
+	BUG_ON(!vmb_blocking_info_cache);
+	BUG_ON(!list_empty(&vmb_blocked_files));
+
+	kmem_cache_destroy(vmb_blocking_info_cache);
+}
+
+static struct vmb_blocking_info *vmb_blocking_alloc_block(
+	struct kmem_cache *cache,
+	const char *filename,
+	const struct file *blocker)
+{
+	struct vmb_blocking_info *block;
+	size_t ret;
+
+	/* Initialize this file's block structure. */
+	block = kmem_cache_alloc(vmb_blocking_info_cache, GFP_KERNEL);
+	if (!block)
+		goto out_alloc_block;
+
+	ret = strlcpy(block->filename, filename, sizeof block->filename);
+	if (ret >= sizeof block->filename) {
+		VMBLOCK_WARNING("filename is too large");
+		kmem_cache_free(vmb_blocking_info_cache, block);
+		goto out_alloc_block;
+	}
+
+	INIT_LIST_HEAD(&block->links);
+	atomic_set(&block->refcount, 1);
+	init_completion(&block->completion);
+	block->blocker = (struct file *)blocker;
+
+out_alloc_block:
+	return block;
+}
+
+static void vmb_blocking_free_block(struct kmem_cache *cache,
+	struct vmb_blocking_info *block)
+{
+	BUG_ON(!cache);
+	BUG_ON(!block);
+
+	kmem_cache_free(cache, block);
+}
+
+static struct vmb_blocking_info *vmb_blocking_get_block(
+	const char *filename,
+	const struct file *blocker)
+{
+	struct vmb_blocking_info *curr_block;
+
+	list_for_each_entry(curr_block, &vmb_blocked_files, links) {
+		if ((blocker == VMBLOCK_UNKNOWN_BLOCKER ||
+			blocker == curr_block->blocker) &&
+			strcmp(curr_block->filename, filename) == 0) {
+			atomic_inc(&curr_block->refcount);
+			return curr_block;
+		}
+	}
+
+	return NULL;
+}
+
+static bool vmb_block_exists(const char *filename)
+{
+	struct vmb_blocking_info *block = vmb_blocking_get_block(filename,
+						VMBLOCK_UNKNOWN_BLOCKER);
+
+	if (block) {
+		/* get_block above will have incremented refcount */
+		atomic_dec(&block->refcount);
+		return true;
+	}
+
+	return false;
+}
+
+static int vmb_blocking_add_file_block(const char *filename,
+	const struct file *blocker)
+{
+	int ret = 0;
+	struct vmb_blocking_info *block;
+
+	BUG_ON(!filename);
+
+	/* Create a new block. */
+	block = vmb_blocking_alloc_block(vmb_blocking_info_cache, filename,
+								blocker);
+	if (!block) {
+		VMBLOCK_WARNING("out of memory");
+		ret = -ENOMEM;
+		goto out_add_file_block;
+	}
+	write_lock(&vmb_blocked_files_lock);
+
+	/*
+	 * Prevent duplicate blocks of any filename.  Done under same lock
+	 * as list addition to ensure check for and adding of file are atomic.
+	 */
+	if (vmb_block_exists(filename)) {
+		VMBLOCK_WARNING("block already exists for [%s]", filename);
+		write_unlock(&vmb_blocked_files_lock);
+		vmb_blocking_free_block(vmb_blocking_info_cache, block);
+		ret = -EEXIST;
+		goto out_add_file_block;
+	}
+
+	list_add_tail(&block->links, &vmb_blocked_files);
+
+	write_unlock(&vmb_blocked_files_lock);
+
+	VMBLOCK_INFO("added block for [%s]", filename);
+
+out_add_file_block:
+	return ret;
+}
+
+static void vmb_blocking_free_complete(const struct file *blocker,
+	struct vmb_blocking_info *block)
+{
+	/*
+	 * struct vmb_blocking_info's, as the result of placing
+	 * a block on a file or directory, reference
+	 * themselves.  When the block is lifted, we need to
+	 * remove this self-reference and handle the result
+	 * appropriately.
+	 */
+	if (atomic_dec_and_test(&block->refcount)) {
+		/* Free blocks without any waiters ... */
+		VMBLOCK_INFO("Freeing block with no waiters for blocker "
+					"[%p] (%s)", blocker, block->filename);
+		vmb_blocking_free_block(vmb_blocking_info_cache, block);
+	} else {
+		/* ... or wakeup the waiting threads */
+		VMBLOCK_INFO("Completing block for blocker "
+					"[%p] (%s)", blocker, block->filename);
+		complete_all(&block->completion);
+	}
+}
+
+static int vmb_blocking_remove_file_block(const char *filename,
+	const struct file *blocker)
+{
+	int ret = 0;
+	struct vmb_blocking_info *block;
+
+	BUG_ON(!filename);
+
+	write_lock(&vmb_blocked_files_lock);
+
+	block = vmb_blocking_get_block(filename, blocker);
+	if (!block) {
+		write_unlock(&vmb_blocked_files_lock);
+		ret = -ENOENT;
+		goto out_remove_file_block;
+	}
+
+	list_del(&block->links);
+	write_unlock(&vmb_blocked_files_lock);
+
+	/* Undo vmb_blocking_get_block's refcount increment first */
+	atomic_dec(&block->refcount);
+
+	/*
+	 * Now remove /our/ reference (as opposed to references by waiting
+	 * threads)
+	 */
+	vmb_blocking_free_complete(blocker, block);
+
+out_remove_file_block:
+	return ret;
+}
+
+static unsigned int vmb_blocking_remove_all_blocks(const struct file *blocker)
+{
+	struct vmb_blocking_info *curr_block, *tmp;
+	/* struct list_head *tmp; */
+	unsigned int removed = 0;
+
+	write_lock(&vmb_blocked_files_lock);
+
+	list_for_each_entry_safe(curr_block, tmp, &vmb_blocked_files, links) {
+		if (blocker == curr_block->blocker ||
+			blocker == VMBLOCK_UNKNOWN_BLOCKER) {
+
+			list_del(&curr_block->links);
+
+			/*
+			 * We count only entries removed from the -list-,
+			 * regardless of whether or not other waiters exist.
+			 */
+			++removed;
+
+			vmb_blocking_free_complete(blocker, curr_block);
+		}
+	}
+
+	write_unlock(&vmb_blocked_files_lock);
+
+	return removed;
+}
+
+static int vmb_blocking_wait_on_file(const char *filename)
+{
+	struct vmb_blocking_info *block;
+	int error = 0;
+
+	BUG_ON(!filename);
+
+	read_lock(&vmb_blocked_files_lock);
+	block = vmb_blocking_get_block(filename, VMBLOCK_UNKNOWN_BLOCKER);
+	read_unlock(&vmb_blocked_files_lock);
+
+	if (!block)
+		/* This file is not blocked, just return */
+		goto out_wait_on_file;
+
+	VMBLOCK_INFO("(%d) Waiting for completion on [%s]",
+						current->pid, filename);
+
+	wait_for_completion(&block->completion);
+
+	VMBLOCK_INFO("(%d) Wokeup from block on [%s]",
+						current->pid, filename);
+
+	/*
+	 * The assumptions here are as follows:
+	 *   1.	The struct vmb_blocking_info holds a reference to itself.
+	 *	(struct vmb_blocking_info's refcount is initialized to 1)
+	 *   2.	struct vmb_blocking_info's self reference is deleted only when
+	 *	it is /also/ removed removed from the block list.
+	 *
+	 * Therefore, if the reference count hits zero, it's because the block
+	 * is no longer in the list, and there is no chance of another thread
+	 * finding and referencing this block between our dec_and_test and
+	 * freeing it.
+	 */
+	if (atomic_dec_and_test(&block->refcount)) {
+		/* We were the last thread, so clean up */
+		VMBLOCK_INFO("(%d) I am the last to wakeup, freeing the "
+				"block on [%s]", current->pid, filename);
+		vmb_blocking_free_block(vmb_blocking_info_cache, block);
+	}
+
+out_wait_on_file:
+	return error;
+}
+
+#ifdef CONFIG_VMBLOCK_DEBUG
+static void vmb_blocking_list_file_blocks(void)
+{
+	struct vmb_blocking_info *curr_block;
+	int count = 0;
+
+	read_lock(&vmb_blocked_files_lock);
+
+	list_for_each_entry(curr_block, &vmb_blocked_files, links) {
+		VMBLOCK_DEBUG("(%d) Filename: [%s], Blocker: [%p]",
+			 count++, curr_block->filename, curr_block->blocker);
+	}
+
+	read_unlock(&vmb_blocked_files_lock);
+
+	if (!count)
+		VMBLOCK_DEBUG("No blocks currently exist");
+}
+#endif
+
+/*
+ * Control section
+ *
+ * The following functions implement the control functionality.
+ */
+
+static ssize_t vmb_control_write(struct file *file, const char __user *buf,
+	size_t cmd, loff_t *ppos)
+{
+	long ret;
+	ssize_t i;
+	char *filename;
+
+#ifdef CONFIG_VMBLOCK_DEBUG
+	if (cmd == VMBLOCK_LIST_FILEBLOCKS) {
+		vmb_blocking_list_file_blocks();
+		return 0;
+	}
+#endif
+
+	filename = getname(buf);
+	ret = PTR_ERR(filename);
+	if (IS_ERR(filename)) {
+		VMBLOCK_WARNING("Could not get filename from user buffer");
+		goto exit;
+	}
+
+	/* Remove all trailing path separators. */
+	for (i = strlen(filename) - 1; i >= 0 && filename[i] == '/'; i--)
+		filename[i] = '\0';
+
+	if (i < 0) {
+		ret = -EINVAL;
+		goto exit_putname;
+	}
+
+	switch (cmd) {
+	case VMBLOCK_ADD_FILEBLOCK:
+		ret = vmb_blocking_add_file_block(filename, file);
+		break;
+	case VMBLOCK_DEL_FILEBLOCK:
+		ret = vmb_blocking_remove_file_block(filename, file);
+		break;
+	default:
+		VMBLOCK_WARNING("unrecognized command (%u) received",
+				  (unsigned)cmd);
+		ret = -EINVAL;
+		break;
+	}
+
+
+exit_putname:
+	putname(filename);
+
+exit:
+	return ret;
+}
+
+static int vmb_control_release(struct inode *inode,	struct file *file)
+{
+	vmb_blocking_remove_all_blocks(file);
+
+	return 0;
+}
+
+static const struct file_operations vmb_control_file_ops = {
+	.owner		= THIS_MODULE,
+	.write		= vmb_control_write,
+	.release	= vmb_control_release,
+};
+
+static struct proc_dir_entry *vmb_control_proc_dir_entry;
+
+static int vmb_control_proc_init(void)
+{
+	int ret = 0;
+
+	struct proc_dir_entry *control_proc_entry;
+	struct proc_dir_entry *control_proc_mountpoint;
+
+	/* Create /proc/fs/vmblock */
+	vmb_control_proc_dir_entry = proc_mkdir(
+					VMBLOCK_CONTROL_PROC_DIRNAME, NULL);
+
+	if (!vmb_control_proc_dir_entry) {
+		VMBLOCK_WARNING("could not create /proc/"
+					VMBLOCK_CONTROL_PROC_DIRNAME);
+		ret = -EINVAL;
+		goto out_control_proc_init;
+	}
+
+	vmb_control_proc_dir_entry->owner = THIS_MODULE;
+
+	/* Create /proc/fs/vmblock/mountPoint */
+	control_proc_mountpoint = proc_mkdir(VMBLOCK_CONTROL_MOUNTPOINT,
+					vmb_control_proc_dir_entry);
+
+	if (!control_proc_mountpoint) {
+		VMBLOCK_WARNING("could not create " VMBLOCK_MOUNT_POINT);
+		remove_proc_entry(VMBLOCK_CONTROL_PROC_DIRNAME, NULL);
+		ret = -EINVAL;
+		goto out_control_proc_init;
+	}
+
+	control_proc_mountpoint->owner = THIS_MODULE;
+
+	/* Create /proc/fs/vmblock/dev */
+	control_proc_entry = create_proc_entry(VMBLOCK_CONTROL_DEVNAME,
+			VMBLOCK_CONTROL_MODE, vmb_control_proc_dir_entry);
+
+	if (!control_proc_entry) {
+		VMBLOCK_WARNING("could not create " VMBLOCK_DEVICE);
+		remove_proc_entry(VMBLOCK_CONTROL_MOUNTPOINT,
+					vmb_control_proc_dir_entry);
+		remove_proc_entry(VMBLOCK_CONTROL_PROC_DIRNAME, NULL);
+		ret = -EINVAL;
+		goto out_control_proc_init;
+	}
+
+	control_proc_entry->proc_fops = &vmb_control_file_ops;
+
+out_control_proc_init:
+	return ret;
+}
+
+static void vmb_control_proc_cleanup(void)
+{
+	if (vmb_control_proc_dir_entry) {
+		remove_proc_entry(VMBLOCK_CONTROL_MOUNTPOINT,
+					vmb_control_proc_dir_entry);
+		remove_proc_entry(VMBLOCK_CONTROL_DEVNAME,
+					vmb_control_proc_dir_entry);
+		remove_proc_entry(VMBLOCK_CONTROL_PROC_DIRNAME, NULL);
+	}
+}
+
+static int __init vmb_control_init(void)
+{
+	int ret;
+
+	ret = vmb_blocking_init();
+	if (ret < 0) {
+		VMBLOCK_WARNING("could not initialize blocking ops");
+		goto out_control_init;
+	}
+
+	ret = vmb_control_proc_init();
+	if (ret < 0) {
+		VMBLOCK_WARNING("could not setup proc device");
+		vmb_blocking_cleanup();
+	}
+
+out_control_init:
+	return ret;
+}
+
+static void vmb_control_cleanup(void)
+{
+	vmb_control_proc_cleanup();
+	vmb_blocking_cleanup();
+}
+
+/*
+ * Module section
+ *
+ * The following functions implement the usual kernel module entry and exit
+ * points.
+ */
+
+static int __init vmb_init(void)
+{
+	int err = vmb_control_init();
+	if (err)
+		goto out;
+
+	err = vmb_fs_init(root);
+
+	if (err)
+		vmb_control_cleanup();
+
+out:
+	return err;
+}
+
+static void __exit vmb_exit(void)
+{
+	vmb_fs_cleanup();
+	vmb_control_cleanup();
+}
+
+module_init(vmb_init);
+module_exit(vmb_exit);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("VMware, Inc.");
+MODULE_DESCRIPTION("VMware Blocking File System");
diff --git a/fs/Makefile b/fs/Makefile
index a1482a5..b42fe8c 100644
--- a/fs/Makefile
+++ b/fs/Makefile
@@ -122,3 +122,4 @@ obj-$(CONFIG_HPPFS)		+= hppfs/
 obj-$(CONFIG_DEBUG_FS)		+= debugfs/
 obj-$(CONFIG_OCFS2_FS)		+= ocfs2/
 obj-$(CONFIG_GFS2_FS)           += gfs2/
+obj-$(CONFIG_VMBLOCK_FS)	+= vmblock/
diff --git a/include/linux/Kbuild b/include/linux/Kbuild
index b68ec09..e6b6bd0 100644
--- a/include/linux/Kbuild
+++ b/include/linux/Kbuild
@@ -161,6 +161,7 @@ header-y += veth.h
 header-y += video_decoder.h
 header-y += video_encoder.h
 header-y += videotext.h
+header-y += vmblock.h
 header-y += x25.h
 
 unifdef-y += acct.h
diff --git a/include/linux/vmblock.h b/include/linux/vmblock.h
new file mode 100644
index 0000000..e70ad81
--- /dev/null
+++ b/include/linux/vmblock.h
@@ -0,0 +1,49 @@
+/*********************************************************
+ * Copyright (C) 2006 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ *
+ *********************************************************/
+
+/*
+ * vmblock.h --
+ *
+ *   User-level interface to the vmblock device.
+ */
+
+#ifndef _LINUX_VMBLOCK_H
+#define _LINUX_VMBLOCK_H
+
+#define VMBLOCK_FS_NAME		"vmblock"
+
+/* Commands for the control half of vmblock driver */
+#define VMBLOCK_ADD_FILEBLOCK		 98
+#define VMBLOCK_DEL_FILEBLOCK		 99
+#ifdef CONFIG_VMBLOCK_DEBUG
+#	define VMBLOCK_LIST_FILEBLOCKS	 100
+#endif
+#define VMBLOCK_CONTROL_DIRNAME	VMBLOCK_FS_NAME
+#define VMBLOCK_CONTROL_DEVNAME	"dev"
+#define VMBLOCK_CONTROL_MOUNTPOINT	"mountPoint"
+#define VMBLOCK_CONTROL_PROC_DIRNAME	"fs/" VMBLOCK_CONTROL_DIRNAME
+
+#define VMBLOCK_MOUNT_POINT	"/proc/" VMBLOCK_CONTROL_PROC_DIRNAME \
+				"/" VMBLOCK_CONTROL_MOUNTPOINT
+#define VMBLOCK_DEVICE		"/proc/" VMBLOCK_CONTROL_PROC_DIRNAME   \
+				"/" VMBLOCK_CONTROL_DEVNAME
+#define VMBLOCK_DEVICE_MODE	O_WRONLY
+#define VMBLOCK_CONTROL(fd, op, path)  write(fd, path, op)
+#define VMBLOCK_CONTROL_MODE	(S_IRUSR | S_IFREG)
+
+#endif /* _LINUX_VMBLOCK_H */
-- 
1.5.5.1.308.g1fbb5

Re: WIKI documentation for building from git

[Marcelo V. <mv...@vm...>]

Hi Zach,

Zachary Drew wrote:
> I'm trying to build open-vm-tools from git on Ubuntu 8.10 and I'm getting
> stuck at the autotools step. Could someone post a brief 'how to build
> starting from git' guide to the wiki? I tried following Adar Dembo's
> suggestion from his 2008.10.13 tar ball announcement:

I'm not yet terribly familiar with the autotools stuff, but I was able to build 
the git code by doing:

. mkdir m4
. autoreconf -install
. ./configure
. make

Could you try those steps and see if you have better luck?

-- 
- Marcelo

[ open-vm-tools-Tracker-2301228 ] Build fails with --disable-multimon in unity

[SourceForge.net <no...@so...>]

Tracker item #2301228, was opened at 2008-11-16 14:15
Message generated for change (Comment added) made by mvanzin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2301228&group_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: libraries
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John Brooks (aspecial)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build fails with --disable-multimon in unity

Initial Comment:
The build of version 2008.10.10 with --disable-multimon (no xinerama support) and with Unity enabled fails in lib/unity/unityPlatformX11.c due to extensive use of the header, functions, and structures from xinerama not contained within #ifndef NO_MULTIMON - making a build with unity and without xinerama impossible. Due to use of structures from xinerama, it's too much for me to resolve myself.

If this isn't something that is intended to be fixed (i.e. a dependency will be made on xinerama), let me know and i'll get the gentoo ebuild updated accordingly - currently it tries to use --disable-multimon whenever xinerama isn't available/enabled.

----------------------------------------------------------------------

Comment By: Marcelo Vanzin (mvanzin)
Date: 2008-11-17 19:56

Message:
Hi John,

To the best of my knowledge, Unity depends on the multimon functionality,
so I guess you'll need to update the ebuild. I'll keep this bug open to add
a similar check in the configure script itself.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2301228&group_id=204462

[ open-vm-tools-Tracker-2298353 ] vmware-user does not autostart

[SourceForge.net <no...@so...>]

Tracker item #2298353, was opened at 2008-11-16 12:46
Message generated for change (Comment added) made by slogan621
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2298353&group_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: vmware-user
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: lucatrv (lucatrv)
Assigned to: Nobody/Anonymous (nobody)
Summary: vmware-user does not autostart

Initial Comment:
Ubuntu Intrepid 8.10
Although the vmware-user.desktop link is present in /etc/xdg/autostart , vmware-user does not start automatically at boot. So copy/past doesn't work.

This has a very quick fix: add the line line "Type=Application" in the file  vmware-user.desktop

$ cat vmware-user.desktop 
[Desktop Entry]
Type=Application
Encoding=UTF-8
Exec=vmware-user-suid-wrapper
Name=VMware User Agent
X-KDE-autostart-phase=1
NoDisplay=true

Now vmware-user starts at boot so copy/paste works.

Please add this very quick fix to the next release...

Thanks

PS. to improve your documentation page (http://open-vm-tools.wiki.sourceforge.net/Packaging) I think you should add under the vmhgfs paragraph (after the fstab description) a phrase telling that if one doesn't want that updatedb indexes all the shared folder it is necessary to add "vmhgfs" in the file /etc/updatedb.conf after "PRUNEFS=". In fact, this was automatically done by the old perl installer.


----------------------------------------------------------------------

Comment By: Syd Logan (slogan621)
Date: 2008-11-17 08:07

Message:
Thanks, we ran into that fix a week or so ago and the fix you described
should be in an upcoming release.

----------------------------------------------------------------------

Comment By: lucatrv (lucatrv)
Date: 2008-11-16 21:50

Message:
Ops, sorry, I didn't notice it was mentioned already. So you can ignore the
last "PS" part of my post.

----------------------------------------------------------------------

Comment By: Ragavan S (ragavan_s)
Date: 2008-11-16 21:20

Message:
Thanks for submitting this. With regards to the documentation suggestion, I
think we already mention this in the vmhgfs section:

"We typically exclude vmhgfs from the locate database as crawling the
Shared Folders is time consuming. To do this, add "vmhgfs" to PRUNEFS
within updatedb's configuration file, typically found in
/etc/updatedb.conf"

Is this what you were suggesting or something else?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2298353&group_id=204462

[ open-vm-tools-Tracker-2301228 ] Build fails with --disable-multimon in unity

[SourceForge.net <no...@so...>]

Tracker item #2301228, was opened at 2008-11-16 15:15
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2301228&group_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: libraries
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John Brooks (aspecial)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build fails with --disable-multimon in unity

Initial Comment:
The build of version 2008.10.10 with --disable-multimon (no xinerama support) and with Unity enabled fails in lib/unity/unityPlatformX11.c due to extensive use of the header, functions, and structures from xinerama not contained within #ifndef NO_MULTIMON - making a build with unity and without xinerama impossible. Due to use of structures from xinerama, it's too much for me to resolve myself.

If this isn't something that is intended to be fixed (i.e. a dependency will be made on xinerama), let me know and i'll get the gentoo ebuild updated accordingly - currently it tries to use --disable-multimon whenever xinerama isn't available/enabled.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2301228&group_id=204462

[ open-vm-tools-Tracker-2298353 ] vmware-user does not autostart

[SourceForge.net <no...@so...>]

Tracker item #2298353, was opened at 2008-11-16 13:46
Message generated for change (Comment added) made by lucatrv
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2298353&group_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: vmware-user
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: lucatrv (lucatrv)
Assigned to: Nobody/Anonymous (nobody)
Summary: vmware-user does not autostart

Initial Comment:
Ubuntu Intrepid 8.10
Although the vmware-user.desktop link is present in /etc/xdg/autostart , vmware-user does not start automatically at boot. So copy/past doesn't work.

This has a very quick fix: add the line line "Type=Application" in the file  vmware-user.desktop

$ cat vmware-user.desktop 
[Desktop Entry]
Type=Application
Encoding=UTF-8
Exec=vmware-user-suid-wrapper
Name=VMware User Agent
X-KDE-autostart-phase=1
NoDisplay=true

Now vmware-user starts at boot so copy/paste works.

Please add this very quick fix to the next release...

Thanks

PS. to improve your documentation page (http://open-vm-tools.wiki.sourceforge.net/Packaging) I think you should add under the vmhgfs paragraph (after the fstab description) a phrase telling that if one doesn't want that updatedb indexes all the shared folder it is necessary to add "vmhgfs" in the file /etc/updatedb.conf after "PRUNEFS=". In fact, this was automatically done by the old perl installer.


----------------------------------------------------------------------

Comment By: lucatrv (lucatrv)
Date: 2008-11-16 22:50

Message:
Ops, sorry, I didn't notice it was mentioned already. So you can ignore the
last "PS" part of my post.

----------------------------------------------------------------------

Comment By: Ragavan S (ragavan_s)
Date: 2008-11-16 22:20

Message:
Thanks for submitting this. With regards to the documentation suggestion, I
think we already mention this in the vmhgfs section:

"We typically exclude vmhgfs from the locate database as crawling the
Shared Folders is time consuming. To do this, add "vmhgfs" to PRUNEFS
within updatedb's configuration file, typically found in
/etc/updatedb.conf"

Is this what you were suggesting or something else?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2298353&group_id=204462

[ open-vm-tools-Tracker-2298353 ] vmware-user does not autostart

[SourceForge.net <no...@so...>]

Tracker item #2298353, was opened at 2008-11-16 04:46
Message generated for change (Comment added) made by ragavan_s
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2298353&group_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: vmware-user
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: lucatrv (lucatrv)
Assigned to: Nobody/Anonymous (nobody)
Summary: vmware-user does not autostart

Initial Comment:
Ubuntu Intrepid 8.10
Although the vmware-user.desktop link is present in /etc/xdg/autostart , vmware-user does not start automatically at boot. So copy/past doesn't work.

This has a very quick fix: add the line line "Type=Application" in the file  vmware-user.desktop

$ cat vmware-user.desktop 
[Desktop Entry]
Type=Application
Encoding=UTF-8
Exec=vmware-user-suid-wrapper
Name=VMware User Agent
X-KDE-autostart-phase=1
NoDisplay=true

Now vmware-user starts at boot so copy/paste works.

Please add this very quick fix to the next release...

Thanks

PS. to improve your documentation page (http://open-vm-tools.wiki.sourceforge.net/Packaging) I think you should add under the vmhgfs paragraph (after the fstab description) a phrase telling that if one doesn't want that updatedb indexes all the shared folder it is necessary to add "vmhgfs" in the file /etc/updatedb.conf after "PRUNEFS=". In fact, this was automatically done by the old perl installer.


----------------------------------------------------------------------

>Comment By: Ragavan S (ragavan_s)
Date: 2008-11-16 13:20

Message:
Thanks for submitting this. With regards to the documentation suggestion, I
think we already mention this in the vmhgfs section:

"We typically exclude vmhgfs from the locate database as crawling the
Shared Folders is time consuming. To do this, add "vmhgfs" to PRUNEFS
within updatedb's configuration file, typically found in
/etc/updatedb.conf"

Is this what you were suggesting or something else?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2298353&group_id=204462

[ open-vm-tools-Tracker-2298353 ] vmware-user does not autostart

[SourceForge.net <no...@so...>]

Tracker item #2298353, was opened at 2008-11-16 13:46
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2298353&group_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: vmware-user
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: lucatrv (lucatrv)
Assigned to: Nobody/Anonymous (nobody)
Summary: vmware-user does not autostart

Initial Comment:
Ubuntu Intrepid 8.10
Although the vmware-user.desktop link is present in /etc/xdg/autostart , vmware-user does not start automatically at boot. So copy/past doesn't work.

This has a very quick fix: add the line line "Type=Application" in the file  vmware-user.desktop

$ cat vmware-user.desktop 
[Desktop Entry]
Type=Application
Encoding=UTF-8
Exec=vmware-user-suid-wrapper
Name=VMware User Agent
X-KDE-autostart-phase=1
NoDisplay=true

Now vmware-user starts at boot so copy/paste works.

Please add this very quick fix to the next release...

Thanks

PS. to improve your documentation page (http://open-vm-tools.wiki.sourceforge.net/Packaging) I think you should add under the vmhgfs paragraph (after the fstab description) a phrase telling that if one doesn't want that updatedb indexes all the shared folder it is necessary to add "vmhgfs" in the file /etc/updatedb.conf after "PRUNEFS=". In fact, this was automatically done by the old perl installer.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2298353&group_id=204462

RE: WIKI documentation for building from git

[Adar D. <ad...@vm...>]

> zdrew@zdrew-ubuntu-32bit-vm:~/vmware/open-vm-tools$ autoconf
> configure.ac:176: error: possibly undefined macro: AM_INIT_AUTOMAKE
>       If this token and others are legitimate, please use
> m4_pattern_allow.
>       See the Autoconf documentation.
> configure.ac:209: error: possibly undefined macro: AM_PROG_CC_C_O
> configure.ac:218: error: possibly undefined macro: AC_PROG_LIBTOOL
> configure.ac:932: error: possibly undefined macro: AM_CONDITIONAL
> zdrew@zdrew-ubuntu-32bit-vm:~/vmware/open-vm-tools$ libtool
> libtool: error: you must specify a MODE.
> zdrew@zdrew-ubuntu-32bit-vm:~/vmware/open-vm-tools$ automake
> configure.ac:66: required directory ./config does not exist
> <followed by another hundred errors>
> 
> Are there missing steps and/or arguments?

Try "autoreconf -I" (or --install). autoreconf will invoke the appropriate steps along the way, including automake, autoconf, aclocal, etc. You may need to create an empty 'm4' subdirectory first.

> P.S. If you're curious, I'm interested in the recent XVideo bug fixes.

Sounds good, except the xorg video drivers aren't part of the open-vm-tools; they're part of the upstream xorg repository. The vmmouse driver had some issues in 8.10 that have seen been corrected; you can get an updated vmmouse package through the latest Intrepid updates.

WIKI documentation for building from git

[Zachary D. <zac...@gm...>]

Hello,

I'm trying to build open-vm-tools from git on Ubuntu 8.10 and I'm getting
stuck at the autotools step. Could someone post a brief 'how to build
starting from git' guide to the wiki? I tried following Adar Dembo's
suggestion from his 2008.10.13 tar ball announcement:

These files can be rebuilt by anyone with the autoconf/libtool/automake
> packages installed locally and as such, probably shouldn't be tracked by
> source control.
>

But that failed immediately:

zdrew@zdrew-ubuntu-32bit-vm:~/vmware/open-vm-tools$ autoconf
configure.ac:176: error: possibly undefined macro: AM_INIT_AUTOMAKE
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:209: error: possibly undefined macro: AM_PROG_CC_C_O
configure.ac:218: error: possibly undefined macro: AC_PROG_LIBTOOL
configure.ac:932: error: possibly undefined macro: AM_CONDITIONAL
zdrew@zdrew-ubuntu-32bit-vm:~/vmware/open-vm-tools$ libtool
libtool: error: you must specify a MODE.
zdrew@zdrew-ubuntu-32bit-vm:~/vmware/open-vm-tools$ automake
configure.ac:66: required directory ./config does not exist
<followed by another hundred errors>

Are there missing steps and/or arguments?

Thanks!

Zach


P.S. If you're curious, I'm interested in the recent XVideo bug fixes.

More list administrativa

[Adar D. <ad...@vm...>]

After noticing that the recent thread with Greg KH was entirely one-sided (his mails were being discarded so it looked like I was speaking to myself), I made a couple of changes to the behavior of the open-vm-tools-devel and open-vm-tools-discuss mailing lists:
1) Posts from non-members are now allowed.
2) To quell spam that may result from the above change, the spam filter will now try to match against the "\[SPAM\]" regexp and discard matched messages.
3) The list names are no longer prepended to email subject lines.

Let's see how this goes, and if things get worse, I'll adjust the behavior further.

[open-vm-tools-devel] [ open-vm-tools-Tracker-1797158 ] Open Virtual Machine Tools for windows

[SourceForge.net <no...@so...>]

Tracker item #1797158, was opened at 2007-09-18 09:05
Message generated for change (Comment added) made by mmoo9154
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=1797158&group_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: None
Group: None
Status: Open
Resolution: None
Priority: 1
Private: No
Submitted By: stopka (stopka2top)
Assigned to: Nobody/Anonymous (nobody)
Summary: Open Virtual Machine Tools for windows

Initial Comment:
Open Virtual Machine Tools for windows users.


----------------------------------------------------------------------

Comment By: Mark Moore (mmoo9154)
Date: 2008-11-13 21:38

Message:
I don't see anything specific here, but I'm a coder that uses VMware Server
under Windows.  I'd be interested in contributing.

----------------------------------------------------------------------

Comment By: ECL (sopwith)
Date: 2007-11-26 10:54

Message:
Logged In: YES 
user_id=18318
Originator: NO

Just updating this bug to note that nothing has happened with it :) If
there is a real and pressing demand for it (e.g. someone who is actively
interested in working on contributing to the Windows tools) please note
that on this bug....

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=1797158&group_id=204462

Re: [open-vm-tools-devel] Getting the kernel modules into Linux mainline

[Adar D. <ad...@vm...>]

> > I'm not sure I see exactly how this will work out as painlessly as you
> > say, so let me describe my understanding of the situation and you can
> > correct my mistakes.
> >
> > Let's suppose we want to continue to ship out-of-tree as well as
> > in-tree drivers. The in-tree drivers are live in a single upstream
> > codebase. This codebase can only produce working drivers for the
> > kernel it ships. The out-of-tree drivers live in a single "downstream"
> > codebase littered with compatibility wrappers as we do today. This
> > codebase can be compiled for virtually any kernel, provided we
> > continue to chase down all kernel API changes and wrap them.
> 
> The problem is you are wanting to continue to maintain and support this
> "downstream" codebase.  If you drop that, it will save you time and
> money and make your whole life easier.  Backporting the upstream kernel
> drivers to the handful of older kernels that are shipped by the distros
> is much simpler than trying to maintain your tangled-web of macros and
> wrapper functions that have been built up to support every kernel ever
> created.

OK, now I see what you're getting at. We've discussed maintaining a few distro kernels "downstream" before; I think our concern was that while this approach works well for a small number of distros, it doesn't scale. Now, you could make the argument that it needn't scale; out-of-tree updates should be the exception, not the rule. I tend to agree, though we'll need to discuss this some more and decide which guests merit this sort of treatment and which don't.

Since we're on the subject of overriding the distro's kernel modules with our own, what mechanism would you recommend for getting this done? I see several options:
1) Add some more logic to the Tools installer. We're part of the way there (we can build modules from source and deploy prebuilt modules), so we could add some overriding logic based on /lib/modules/updates or something.
2) Use dkms. We'd probably need to ship dkms with the Tools so that this will work on guests that don't come with dkms pre-installed. But I believe dkms is capable of both deploying prebuilt modules as well as cleanly overriding distro modules with its own.
3) Rely on distro driver update programs. Red Hat's driver update program mentions that we can ship a modprobe.d file that will override a Red Hat module in favor of own distributed by a hardware vendor (see "Overriding a Red Hat supplied driver" at http://driverupdateprogram.com). Of course, this method would only work for those distros that support a driver update program, which I believe is RHEL5, SLES9, and SLES10 (and I don't know whether Novell's partner driver process supports this sort of operation).

> I'm guessing that you can remove over 2/3 of your code base if this were
> to happen.
> 
> Note that you are pretty much the only company trying to do this kind of
> thing.  Have you ever thought that perhaps this might not be the correct
> model?  Or did you just think that you all were somehow smarter than
> everyone else?  :)

I plead the fifth. :)

But seriously, I don't know for sure why we go to such lengths to get modules installed in people's kernels. I know that we've done it this way for a long time, and so I'm sure there's enough momentum behind it that it's difficult to change.

If you could point me to some references online that describe how other companies approach this problem, I'd greatly appreciate it.

Re: [open-vm-tools-devel] Getting the kernel modules into Linux mainline

[Adar D. <ad...@vm...>]

> > Since we're on the subject, I also want to say a few words about
> > upstreaming VMware's kernel modules. In general we're getting more and
> > more comfortable about upstreaming as some of us have been socializing
> > the idea within the company. I think the remaining obstacle is this
> > idea that once our code is upstream, we are no longer acting as the
> > distributor, which means we can no longer control its destiny. We've
> > shipped out-of-tree modules for years now and have grown accustomed to
> > the control that this gives us; among other things, we can do things
> > like release updated modules simultaneously with our products, or make
> > whatever changes we want regardless of how locked down the affected
> > distros might be (for example, we can add a new feature to a module
> > intended for a distro that's been declared end-of-life by its vendor).
> > It's very difficult to cede this control once you've enjoyed it for
> > many product releases, which is partly why progress has been slow. To
> > mitigate this problem, we're trying to understand whether, after
> > upstreaming, we can gain some control back by working more closely
> > with distros so that new features or changes that are important to us
> > can be backported into existing distro releases in time for, say, a
> > VMware product release. I don't have any details to share yet, but I'm
> > sure either Ragavan or myself will say more about this in the near
> > future.
> 
> I don't see why you can't continue to still ship your drivers
> out-of-tree just fine, as you do today, if the code is also in the
> kernel tree as well.
> 
> Why do you think this is somehow "giving up control"?  How does this
> prevent you from still providing specific modules for specific distros,
> pre-build and ready to go?
> 
> Overall, it will end up saving you engineering time and effort if your
> code gets into the tree, as 75% of your driver lines of code will go
> away (no need for the multiple layers of indirection to handle zillions
> of kernel versions.)
> 
> If you look around, this works just fine for almost all hardware
> vendors, so it's not like this is a new model of doing work or anything
> :)

I'm not sure I see exactly how this will work out as painlessly as you say, so let me describe my understanding of the situation and you can correct my mistakes.

Let's suppose we want to continue to ship out-of-tree as well as in-tree drivers. The in-tree drivers are live in a single upstream codebase. This codebase can only produce working drivers for the kernel it ships. The out-of-tree drivers live in a single "downstream" codebase littered with compatibility wrappers as we do today. This codebase can be compiled for virtually any kernel, provided we continue to chase down all kernel API changes and wrap them.

Distros will periodically snapshot the upstream kernel and ship some version of our drivers. Additionally, we will periodically snapshot our downstream source and ship a large number of prebuilt drivers and the source itself as part of the VMware Tools, as we do today. Any given VM may or may not have some version of the drivers provided by the distro itself. When installing VMware Tools, our installer will need to choose whether to install the drivers we provide, or to depend on the drivers already found on the system. Some of this logic already exists in our installer today and we can extend it to check the versions of the drivers to make decisions like these, or we can ship dkms in our installer and use it to do this work. Also, it's not enough that these decisions be made when installing or upgrading VMware Tools; they also need to be made when the distro's kernel is upgraded. Again, this is something that dkms can do at boot-time.

With this system in place, VMware is in a position to provide driver updates as it sees fit via the VMware Tools, and to deliver drivers via upstream for the best possible out-of-the-box experience. However, we've paid some high prices to get here:
1) All of our prebuilt driver infrastructure must live on and we must continue to add the latest distros as they are released.
2) We must maintain a separate "downstream" codebase which will continually subject us to API chasing headaches.
3) The "downstream" codebase is essentially a fork of the upstream codebase, so merging changes between the two is painful.
4) There are quite a few moving parts on the user's system tasked with making sure the user has the latest drivers, either from VMware or from the distro. The more complicated the system, the more fragile it will be.
5) The "downstream" codebase is released on VMware's product release schedule. Since it is distro-independent, each of its releases will need to be tested against each distro release. This is a sizable m by n testing matrix.

So, what am I missing?

Re: [open-vm-tools-devel] Getting the kernel modules into Linux mainline

[Chris M. <ma...@ch...>]

Hi Adar

Thanks for the comprehensive response; I did do a little further cosmetic
work on vmblock which I'll post here after I've tried your test code, but to
be honest I've not had much hacking time since my son was born in August!  I
agree that the future is probably userspace anyway so I'll park it for now,
and maybe take a look at the other modules you suggest.

cheers
Chris

Re: [open-vm-tools-devel] Getting the kernel modules into Linux mainline

[Adar D. <ad...@vm...>]

Chris,

I'm sorry that none of us replied to your mail, but better 3 months late than never, right?

Thanks very much for taking the time to go through the vmblock code and cleaning it up. As a developer I can imagine how annoying it must be to translate a non-trivial piece of code from one coding style to another, so I very much appreciate your perseverance in the matter.

Before I get to your patch, let's discuss the more interesting issue of vmblock's future. As you surmised, vmblock-fuse was written to replace vmblock. This was done primarily because the informal feedback we received from some kernel developers suggested that the design of vmblock is a non-starter for the kernel. See http://bugzilla.redhat.com/show_bug.cgi?id=294341 for Christoph Hellwig's comments and http://sourceforge.net/mailarchive/message.php?msg_name=46E6FDEC.3090700%40codemonkey.ws for Anthony Liguori's comments. Unfortunately, vmblock-fuse isn't quite ready for prime-time, but until its code is part of open-vm-tools it's difficult to describe exactly why (the open-sourcing process is taking longer than I expected). I suggest that you table the work on vmblock for the time being, and once vmblock-fuse is part of open-vm-tools we can have a more productive discussion about the future of vmblock. How does that sound?

If you do want to continue preparing VMware module code for upstream inclusion, first of all, thanks, and secondly, I recommend vmmemctl. It's a very simple module (especially once the compat glue is removed), it hasn't changed in a long time, and as Linux has recently gained kvm and xen balloon modules, I imagine the VMware one will be fairly non-controversial. Another alternative is the vmxnet module, which is a straightforward paravirtualized network card. The one issue there might be the morphing "feature", which may require us to merge the vmxnet code into the existing upstream pcnet32 module. If you're interested in this, let me know and I'll provide more details.

Since we're on the subject, I also want to say a few words about upstreaming VMware's kernel modules. In general we're getting more and more comfortable about upstreaming as some of us have been socializing the idea within the company. I think the remaining obstacle is this idea that once our code is upstream, we are no longer acting as the distributor, which means we can no longer control its destiny. We've shipped out-of-tree modules for years now and have grown accustomed to the control that this gives us; among other things, we can do things like release updated modules simultaneously with our products, or make whatever changes we want regardless of how locked down the affected distros might be (for example, we can add a new feature to a module intended for a distro that's been declared end-of-life by its vendor). It's very difficult to cede this control once you've enjoyed it for many product releases, which is partly why progress has been slow. To mitigate this problem, we're trying to understand whether, after upstreaming, we can gain some control back by working more closely with distros so that new features or changes that are important to us can be backported into existing distro releases in time for, say, a VMware product release. I don't have any details to share yet, but I'm sure either Ragavan or myself will say more about this in the near future.

Overall I think your vmblock patch is a solid improvement. I didn't look so much at the functionality as I imagine it's the same as before, minus compat glue. If there's something in particular you'd like me to pay closer attention to, let me know. Since you're working on vmblock, I've attached two unit test programs that you might find useful. vmblocktest.c is a general stress test we've used on all of our vmblock implementations (fuse, Linux, FreeBSD, and Solaris). manual-blocker.c was written by Daniel and used for testing vmblock-fuse. You should be able to build both with a minimum of fuss, but let me know if you have issues there.

Here are my (cosmetic) comments:
- The PURPOSE and TESTING portions are especially useful; we're suffering from a dearth of documentation.
- The overloaded interface you mention in the test code was also discussed by Dan Benamy and Miklos at the time that Dan was writing vmblock-fuse. In his implementation he's opted for a new interface where a character representing the command and the path are concatenated and sent to the driver via a single write(2). You can see view the thread at http://article.gmane.org/gmane.comp.file-systems.fuse.devel/6533, if you're interested.
- In Kconfig, some of the capitalization of "VMware" is inconsistent; could you fix that?
- Also in Kconfig, the driver should probably be referred to as a "blocking" driver instead of a "block" driver; that should alleviate any confusion regarding vmblock and the block layer.
- In Makefile, the indentation for the backticks isn't consistent. I'm not sure if you care about that.

Again, thanks for helping us out with this effort!
 

[open-vm-tools-devel] [ open-vm-tools-Tracker-2209565 ] vmware vmxnet fail after hibernate/resume

[SourceForge.net <no...@so...>]

Tracker item #2209565, was opened at 2008-10-30 04:20
Message generated for change (Comment added) made by adembo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2209565&group_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: 3
Private: No
Submitted By: Dominique Leuenberger (dimstar)
Assigned to: Nobody/Anonymous (nobody)
Summary: vmware vmxnet fail after hibernate/resume

Initial Comment:
* Bug copied from bugzilla.novell.com / reported by openSUSE user                 *
* Clarification: Factory means a transient state of openSUSE 11.1 development *
* Due to a feature freeze, there is still version 2008.09.03 in the repositories     *
* Any help woukd be appreciated in this case                                                  *
* Original bug address: https://bugzilla.novell.com/show_bug.cgi?id=439046     *

after hibernate/resume, the VM`s nic is unusable, forwarding no packets
anymore.

"modprobe -r vmxnet" hangs for a short time and gives:

vmxnet_close: Pending tx = 4
vmxnet_close: Failed to finish all pending tx.
Is the related vmxnet device disabled?
This virtual machine may be in an inconsistent state.
Adapter not morphed. read magic: 0x00002934
vmxnet 0000:02:01.0: PCI INT A disabled


after reload of that module (modprobe vmxnet) all is fine again.

dmesg on reload:

VMware vmxnet virtual NIC driver
vmxnet 0000:02:01.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
Found vmxnet/PCI at 0x2024, irq 19.
features:
numRxBuffers = 100, numRxBuffers2 = 1
eth0: no IPv6 routers present

- latest factory
- 2.6.27.1-2-pae 
- vmware-kmp-pae-2008.09.03_2.6.27.1_2.1-5.17
- vmware ws 6.5


----------------------------------------------------------------------

Comment By: Adar Dembo (adembo)
Date: 2008-11-07 00:09

Message:
Thanks for filing this bug.

I spoke to one of our guest networking engineers who said that the vmxnet
driver has never supported guest hibernate properly, in that it doesn't
remorph the device backend from vlance to vmxnet upon guest resume. To do
that we'd probably need to add .suspend and .resume methods to the
pci_driver struct in the driver. All kernels are affected by this, not just
openSUSE, though I don't think it's too serious of an issue given that most
VMware users will likely save the state of their guest by suspending the
entire VM (via suspend/resume) instead of hibernating the guest OS and
powering off the VM.

Given that this isn't a regression, I've lowered the priority.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2209565&group_id=204462

[open-vm-tools-devel] [ open-vm-tools-Tracker-2209565 ] vmware vmxnet fail after hibernate/resume

[SourceForge.net <no...@so...>]

Tracker item #2209565, was opened at 2008-10-30 04:20
Message generated for change (Settings changed) made by adembo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2209565&group_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: 3
Private: No
Submitted By: Dominique Leuenberger (dimstar)
Assigned to: Nobody/Anonymous (nobody)
Summary: vmware vmxnet fail after hibernate/resume

Initial Comment:
* Bug copied from bugzilla.novell.com / reported by openSUSE user                 *
* Clarification: Factory means a transient state of openSUSE 11.1 development *
* Due to a feature freeze, there is still version 2008.09.03 in the repositories     *
* Any help woukd be appreciated in this case                                                  *
* Original bug address: https://bugzilla.novell.com/show_bug.cgi?id=439046     *

after hibernate/resume, the VM`s nic is unusable, forwarding no packets
anymore.

"modprobe -r vmxnet" hangs for a short time and gives:

vmxnet_close: Pending tx = 4
vmxnet_close: Failed to finish all pending tx.
Is the related vmxnet device disabled?
This virtual machine may be in an inconsistent state.
Adapter not morphed. read magic: 0x00002934
vmxnet 0000:02:01.0: PCI INT A disabled


after reload of that module (modprobe vmxnet) all is fine again.

dmesg on reload:

VMware vmxnet virtual NIC driver
vmxnet 0000:02:01.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
Found vmxnet/PCI at 0x2024, irq 19.
features:
numRxBuffers = 100, numRxBuffers2 = 1
eth0: no IPv6 routers present

- latest factory
- 2.6.27.1-2-pae 
- vmware-kmp-pae-2008.09.03_2.6.27.1_2.1-5.17
- vmware ws 6.5


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2209565&group_id=204462

Re: [open-vm-tools-devel] Toolbox documentation ?

[Ragavan S <rag...@gm...>]

Hi Denis,

On Fri, Oct 31, 2008 at 1:57 AM, Denis Leroy <de...@po...> wrote:
> We noticed that clicking on the Help button of the vmware toolbox
> generates an error message. Looking at the code, it expects
> documentation to live in /usr/lib/vmawre-tools/hlp, but the tarball
> doesn't seem to include any...

Thanks for reporting this. I've opened a bug to track this at
https://sourceforge.net/tracker/index.php?func=detail&aid=2222340&group_id=204462&atid=989708

Regards,
Ragavan

[open-vm-tools-devel] [ open-vm-tools-Tracker-2222340 ] Toolbox documentation missing

[SourceForge.net <no...@so...>]

Tracker item #2222340, was opened at 2008-11-04 12:51
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2222340&group_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: toolbox
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ragavan S (ragavan_s)
Assigned to: Nobody/Anonymous (nobody)
Summary: Toolbox documentation missing

Initial Comment:
As reported by Denis Leroy at https://sourceforge.net/mailarchive/message.php?msg_name=490AD68D.3090804%40poolshark.org

We noticed that clicking on the Help button of the vmware toolbox
generates an error message. Looking at the code, it expects
documentation to live in /usr/lib/vmawre-tools/hlp, but the tarball
doesn't seem to include any...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2222340&group_id=204462

[open-vm-tools-devel] [ open-vm-tools-Tracker-2205584 ] unable to initialize blocking driver

[SourceForge.net <no...@so...>]

Tracker item #2205584, was opened at 2008-10-28 15:12
Message generated for change (Comment added) made by mvanzin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2205584&group_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: vmware-user
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Adam (aer0)
Assigned to: Nobody/Anonymous (nobody)
Summary: unable to initialize blocking driver

Initial Comment:
Ubuntu 8.1
After installing, tried to invoke vmware-user.  For the unable to initialize error message.  Mouse is locked in vm session, but resolution resizing seems to work.  

----------------------------------------------------------------------

Comment By: Marcelo Vanzin (mvanzin)
Date: 2008-10-31 18:10

Message:
Hi Adam, I have a few questions:

. what is the distro / kernel you're using?
. is the vmblock kernel module loaded?
. are you running as root? If you're not, you should be running
"vmware-user-suid-wrapper" instead, and that binary should be suid root
(owned by root with mode 4755).

. for the crash issue, do you have gdb installed? If you do, could you run
vmware-user inside gdb and get a better stack trace (once it crashes,
running "bt" should give you better information)? Otherwise, could you
attach your vmware-user binary to the bug so I can try to reproduce it?

I just built the latest open-vm-tools code from git on an Ubuntu 8.04 VM
and vmware-user seems to be working fine (although I don't have the Unity
code compiled in).


----------------------------------------------------------------------

Comment By: Adam (aer0)
Date: 2008-10-28 15:54

Message:
Here is a stack trace from the invocation as root.  It works for about 1s
before crashing:

adam@cdl2:~$ vmware-user failed to initialize blocking driver.  
Error in the RPC recieve loop: RpcIn: Unable to send            
Another instance of VMwareUser may be running.                 //its
not... 

*** glibc detected *** vmware-user: free(): invalid pointer: 0x0966f3a0
***
======= Backtrace: =========                                              

/lib/tls/i686/cmov/libc.so.6[0xb74573f4]                                  

/lib/tls/i686/cmov/libc.so.6(cfree+0x96)[0xb7459456]                      

/usr/lib/libglib-2.0.so.0(g_free+0x36)[0xb770bc06]                        

vmware-user[0x804e26b]                                                    

vmware-user[0x804e368]                                                    

vmware-user[0x805641d]                                                    

vmware-user[0x8058ef6]                                                    

vmware-user[0x80575e9]                                                    

/usr/lib/libglib-2.0.so.0[0xb7703e26]                                     

/usr/lib/libglib-2.0.so.0(g_main_context_dispatch+0x1e8)[0xb77036f8]      

/usr/lib/libglib-2.0.so.0[0xb7706da3]                                     

/usr/lib/libglib-2.0.so.0(g_main_loop_run+0x1d2)[0xb77072c2]              

/usr/lib/libgtk-x11-2.0.so.0(gtk_main+0xb9)[0xb7c573a9]                   

vmware-user[0x8057375]                                                    

/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb73fe685]          

vmware-user[0x804d211]                                                    

======= Memory map: ========                                              

08048000-080a6000 r-xp 00000000 08:01 820888    
/usr/local/bin/vmware-user
080a6000-080a7000 r--p 0005d000 08:01 820888    
/usr/local/bin/vmware-user
080a7000-080a8000 rw-p 0005e000 08:01 820888    
/usr/local/bin/vmware-user
080a8000-08136000 rw-p 080a8000 00:00 0                                   

09661000-096a4000 rw-p 09661000 00:00 0          [heap]                   

b70f1000-b70fe000 r-xp 00000000 08:01 33050      /lib/libgcc_s.so.1       

b70fe000-b70ff000 r--p 0000c000 08:01 33050      /lib/libgcc_s.so.1       

b70ff000-b7100000 rw-p 0000d000 08:01 33050      /lib/libgcc_s.so.1       

b7100000-b7121000 rw-p b7100000 00:00 0                                   

b7121000-b7200000 ---p b7121000 00:00 0                                   

b7203000-b720d000 r-xp 00000000 08:01 50397     
/lib/tls/i686/cmov/libnss_files-2.8.90.so
b720d000-b720e000 r--p 00009000 08:01 50397     
/lib/tls/i686/cmov/libnss_files-2.8.90.so
b720e000-b720f000 rw-p 0000a000 08:01 50397     
/lib/tls/i686/cmov/libnss_files-2.8.90.so
b720f000-b7218000 r-xp 00000000 08:01 50401     
/lib/tls/i686/cmov/libnss_nis-2.8.90.so  
b7218000-b7219000 r--p 00008000 08:01 50401     
/lib/tls/i686/cmov/libnss_nis-2.8.90.so  
b7219000-b721a000 rw-p 00009000 08:01 50401     
/lib/tls/i686/cmov/libnss_nis-2.8.90.so  
b721a000-b7221000 r-xp 00000000 08:01 50393     
/lib/tls/i686/cmov/libnss_compat-2.8.90.so
b7221000-b7222000 r--p 00006000 08:01 50393     
/lib/tls/i686/cmov/libnss_compat-2.8.90.so
b7222000-b7223000 rw-p 00007000 08:01 50393     
/lib/tls/i686/cmov/libnss_compat-2.8.90.so
b7234000-b7315000 r--p 00000000 08:01 771203    
/usr/lib/locale/en_US.utf8/LC_COLLATE
b7315000-b7354000 r--p 00000000 08:01 771204    
/usr/lib/locale/en_US.utf8/LC_CTYPE
b7354000-b7357000 rw-p b7354000 00:00 0
b7357000-b7358000 r-xp 00000000 08:01 748141    
/usr/lib/libxcb-xlib.so.0.0.0
b7358000-b7359000 r--p 00000000 08:01 748141    
/usr/lib/libxcb-xlib.so.0.0.0
b7359000-b735a000 rw-p 00001000 08:01 748141    
/usr/lib/libxcb-xlib.so.0.0.0
b735a000-b7382000 r-xp 00000000 08:01 32880      /lib/libpcre.so.3.12.1
b7382000-b7383000 r--p 00027000 08:01 32880      /lib/libpcre.so.3.12.1
b7383000-b7384000 rw-p 00028000 08:01 32880      /lib/libpcre.so.3.12.1
b7384000-b7399000 r-xp 00000000 08:01 50391     
/lib/tls/i686/cmov/libnsl-2.8.90.so
b7399000-b739a000 r--p 00014000 08:01 50391     
/lib/tls/i686/cmov/libnsl-2.8.90.so
b739a000-b739b000 rw-p 00015000 08:01 50391     
/lib/tls/i686/cmov/libnsl-2.8.90.so
b739b000-b739d000 rw-p b739b000 00:00 0
b739d000-b73c1000 r-xp 00000000 08:01 747214    
/usr/lib/libexpat.so.1.5.2
b73c1000-b73c3000 r--p 00023000 08:01 747214    
/usr/lib/libexpat.so.1.5.2
b73c3000-b73c4000 rw-p 00025000 08:01 747214    
/usr/lib/libexpat.so.1.5.2
b73c4000-b73c5000 rw-p b73c4000 00:00 0
b73c5000-b73c9000 r-xp 00000000 08:01 746986    
/usr/lib/libXdmcp.so.6.0.0
b73c9000-b73ca000 rw-p 00003000 08:01 746986    
/usr/lib/libXdmcp.so.6.0.0
b73ca000-b73cc000 r-xp 00000000 08:01 746975     /usr/lib/libXau.so.6.0.0
b73cc000-b73cd000 rw-p 00001000 08:01 746975     /usr/lib/libXau.so.6.0.0
b73cd000-b73e5000 r-xp 00000000 08:01 32892      /lib/libselinux.so.1
b73e5000-b73e6000 r--p 00017000 08:01 32892      /lib/libselinux.so.1
b73e6000-b73e7000 rw-p 00018000 08:01 32892      /lib/libselinux.so.1
b73e7000-b73e8000 rw-p b73e7000 00:00 0
b73e8000-b7540000 r-xp 00000000 08:01 50380      /lib/tl
[1]+  Aborted                 sudo vmware-user


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2205584&group_id=204462

[open-vm-tools-devel] Toolbox documentation ?

[Denis L. <de...@po...>]

We noticed that clicking on the Help button of the vmware toolbox 
generates an error message. Looking at the code, it expects 
documentation to live in /usr/lib/vmawre-tools/hlp, but the tarball 
doesn't seem to include any...