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

[Anthony L. <an...@co...>]

Adar Dembo wrote:
>> If my understanding of vmblock is correct, I strongly doubt 
>> it would be 
>> 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). 
>
> 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.
>   

Ah, this makes a lot more sense!  Thanks for the explanation.

> 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.
>   

Very interesting problem, I'll look and see if I can't find a clever 
solution.

Regards,

Anthony Liguori

> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> open-vm-tools-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel
>
>