Re: [open-vm-tools-devel] Use of the vmblock driver

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

> I'm going through the vm-tools code now and I think I'm=20
> starting to get=20
> my head around them.  The one bit that still puzzles me is why the=20
> "vmblock" driver is needed.  I see that it is only used for DnD and=20
> copy/paste of a file.
>=20
> As far as I can tell, vmblock implements a mandatory file=20
> locking that=20
> is guaranteed to work on any filesystem.  I can understand=20
> why one might=20
> want to do this in general but I can't seem to figure out a=20
> reason why=20
> DnD or copy/paste is special here verses any other application.
>=20
> Am I correct in assuming that this could be changed to doing posix=20
> advisory locking and for filesystems that don't support it, just live=20
> with the potential race conditions?
>=20
> If my understanding of vmblock is correct, I strongly doubt=20
> it would be=20
> well received on LKML which is why I ask about alternatives :-)

Our DnD/FCP implementations are gtk-based and rely on a physical file =
copy
from one execution environment (host or guest) and into another, usually =
into
a staging directory. Because you can copy a file of arbitrary size, the
operation can take a long time. Unfortunately for us, gtk will abort DnD
operations if too much time elapses (hard-coded via DROP_ABORT_TIME, I
think).=20

This means we need to complete the DnD operation quickly, then somehow =
block
the target application so that it doesn't try and access the file that =
was
dropped until the transfer is done. I don't think advisory locks would =
work
here, because there's no guarantee that the target application will obey
them. Indeed, I doubt any applications will check for an advisory lock =
prior
to accessing a dropped file, though I have no evidence to support this =
claim.

So, one way of solving this problem is via a filesystem like vmblock. =
Another
way might be by giving the target application an HTTP-based URI, then =
run an
HTTP server in vmware-user and  hope that the target app won't mind when =
we
block it on a socket read while we complete the file transfer. We've
discussed this approach a bit, but we're worried that not all apps will
understand HTTP-based URIs.

I think we could accomplish the same goal using a stackable filesystem =
or
using FUSE, but we wanted to fix this for older 2.4 kernels too, and =
support
for FUSE and stackable filesystems isn't very good in such kernels.

Note that vmblock is also used by the Linux Workstation UI on the host =
for
the same purpose.