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

[open-vm-tools-devel] FreeBSD 7.0 building

[Ernest G. W. I. <ern...@gm...>]

I am trying to compile:
open-vm-tools-2008.09.03-114782
on FreeBSD 7

First I get an error during configure stating:
configure: error: libXss not found. Please configure without Unity (using
--disable-unity) or install the libXss devel package

Even though I do have libXss installed via FreeBSD ports:
cd /usr/ports/x11/libX11
make install clean

So I am forced to configure like this:
./configure --disable-unity


So I get through configure and try to make and get:
/usr/src/open-vm-tools-2008.09.03-114782/lib/include/file.h:49:38: error:
syslimits.h: No such file or directory

But I do have syslimits.h in two places:
/usr/include/sys/syslimits.h
/usr/src/sys/sys/syslimits.h

Any idea why file.h can't find my syslimits.h?

Thank you,

Ernie

[open-vm-tools-devel] [ open-vm-tools-Tracker-2064471 ] FEATURE:control vm recording by toolbox

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

Tracker item #2064471, was opened at 2008-08-21 03:41
Message generated for change (Settings changed) made by adembo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2064471&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: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: ven (ven9)
Assigned to: Nobody/Anonymous (nobody)
Summary: FEATURE:control vm recording by toolbox

Initial Comment:
A patch that affects both vmware-toolbox and vmware-toolbox-cmd, adding start/stop recording functionalities for them. It adds a new GuestApp routine, through vmware backdoor, to do it, a new panel for toolbox and a new command for toolbox-cmd as UI.
This patch is based on 2008.08.08 release. I have already posted a version in devel mailing list, now I submit to tracker for simpler tracking.
Thanks to Adar's review. More comments are welcomed.

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-25 14:54

Message:
Thanks, Yiwen. I committed all of the patches.

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

Comment By: ven (ven9)
Date: 2008-09-24 02:18

Message:
Thanks for another reviewer.
The parameter name suggestion in GuestApp_ControlRecord is good for me. 
Root protection for record may be not necessary from my point of view. Do
we all agree with that?
I checked the mnemonics in toolbox. There is a conflict between r of
record tab and start button, which are all added by me. Now I change to s
of start and no conflict is seen.
Here is another patch for above changes.
File Added: 0001-Fix-according-to-Marcelo-s-comments.patch

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-22 18:39

Message:
Yiwen, here are some comments from Marcelo. He's having trouble using his
SF account so I'm posting this on his behalf; I think he's subscribed to
bug updates so feel free to respond.

Looks OK to me; I'd just choose a better name for the argument to
GuestApp_ControlRecord; what you'd passing is not really a "mode", but a
command
(i.e., "start recoding" and other commands defined in
statelogger_backdoor_def.h).

Also, the "root protection" in the Toolbox, for this particular case, is
pretty
useless, for reasons I guess we all know.

I'd also double-check if the mnemonics don't conflict with any existing
controls
in the UI.


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

Comment By: ven (ven9)
Date: 2008-09-17 19:35

Message:
Thank you for your kindness and patience:)
I am sorry for all the inconvenience. Since I started the patch before
2008.09.03, and I am new to git, I don't know an easy way to move previous
work along with its history. Hopefully there are no greate conflicts.

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-17 19:29

Message:
Don't worry, it was a learning exercise for me too; I learned about
git-merge and what a wonderful command it is.

Since you're working within a git repo, all you should need to do is 'git
pull', which will fetch the latest contents of the main open-vm-tools repo
(using git-fetch) and then merge them into your repo, accounting for any
local changes you've made that the main repo didn't have (using git-merge).
The merge will be automatic unless there are conflicts, at which point
you'll be prompted to make a three-way merge.

In this case, here's what I had to do:
- create a new branch named 'yiwen-patches' based on before 2008.09.03.
- switch to 'yiwen-patches'.
- apply your patchset (which commits them to that branch using the commit
details you provided in the patchset).
- switch back to the main branch.
- use git-merge to merge 'yiwen-patches' to the main branch. This brought
in all changes on 'yiwen-patches' which was just your patchset. There were
no conflicts, so it was all automatic.


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

Comment By: ven (ven9)
Date: 2008-09-17 19:24

Message:
Thank you for your kindness and patience:)
I am sorry for all the inconvenience. Since I started the patch before
2008.09.03, and I am new to git, I don't know an easy way to move previous
work along with its history. Hopefully there are no greate conflicts.

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-17 19:11

Message:
Yiwen, thanks for being so patient. I tried the latest patchset and was
able to get it to apply with a little bit of branching. In the future,
please make sure that the patches you send are based on the latest HEAD in
the git repo (yours were based on an older HEAD, before the 2008.09.03
refresh, which necessitated some merging on my part).

I'll forgo actually pushing your patches to the open-vm-tools repo until
we can get them reviewed by another reviewer; I'll try and round up another
member of our team.


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

Comment By: ven (ven9)
Date: 2008-09-17 00:16

Message:
I did another experiment. The failure of applying my patches should result
from that I created git control data at a cpdeeper level than the public
repository did. Sorry for the mistake.
I add prefix for file names in the new patches. I hope all issues
addressed have been resolved now.
File Added: newpatch.tar.gz

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

Comment By: ven (ven9)
Date: 2008-09-16 19:13

Message:
Thanks, Adar. Sorry for the late response due to a local festival.
I tested the patch files as follows:
1. Get an open-vm-tools tarball and extract. The source directory looks
like open-vm-tools-yyyy.mm.dd-build/;
2. Enter the directory, initialize a repository (git init, git add ., git
commit);
3. In the top level of source directory mentioned above, git am each patch
file, or use wildcard.
Since I stayed the top level of source directory, the file names in the
patch look fine to me. Perhaps your git profiles are in a higher level. If
it doesn't work, the file names may have to been modified explicitily.
I will fix other issues and submit them soon.

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-13 15:11

Message:
Thanks, Yiwhen. The screenshots look good; no problems there.

I'm still having some issues applying your patches, though:
- For each patch, make sure your e-mail address is listed. Some of them
show root@localhost.localdomain.
- For each patch, provide an explicit commit message title and details.
Some of the patches show "put your commit message title" as the message
title and "put your commit message details" in the details.
- Don't worry about "testing done" and "reviewers" if there aren't any for
a particular patch.
- Most importantly, all the file paths in your patches lack an
"open-vm-tools/" prefix. This means that when I try to apply them using
git-am, git can't find the files to patch. Could you either rebuild your
patches with the prefix in place in the file paths, or explain to me how I
should use git-am (or git-apply) so that I can connect the files in your
patches to my files?

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

Comment By: ven (ven9)
Date: 2008-09-11 05:39

Message:
Thank you for the comments. They sound reasonable. I have made adjust.
I have made ( and tested ) patch chain along with required screenshots.
They are packed in the attachment. The button layout may not be elegant for
various window size, though.
File Added: commit.tar.gz

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-11 01:22

Message:
I've looked at your second patch, and here is another round of comments:
- I'm trying to use git's workflow to incorporate your patches. To that
end, could you use git-format-patch to format your patches? That way I
should be able to use git-am to apply them easily (so make sure you can use
git-am locally to apply them).
- I'd like to see a screenshot of the new tab you've added to the gtk
toolbox. I'd also appreciate a screenshot of the error presented by
Toolsmain_MsgBox.
- In GuestApp_ControlRecord, refer to statelogger_backdoor_def.h without
the path. That way, we could move statelogger_backdoor_def.h to a new
location in the future without updating this comment.
- Don't bother calling out the isolation flag in RECORD_VMX_ERR. We cover
them exhaustively in the product manuals, and mentioning it by name in this
code will make it harder to change the name of the flag in the future.
- I have some cosmetic suggestions regarding the wording in
RECORD_VMX_ERR. Here's an alternative wording:
"Error, the Record/Replay control operation failed. This could be for one
of the following reasons:\n" \
"1. You are running an old version of a VMware product." \
"2. Your product has disabled these controls. To enable them, consult the
product documentation.\n\n" \
"3. You tried to start a recording while already recording.\n\n" \
"4. You tried to stop a recording while already not recording.\n\n"


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

Comment By: ven (ven9)
Date: 2008-09-09 23:04

Message:
Correct my typos and incorporate the new macros. Also add some
informational error message.
The new patch is applied after the first one.
File Added: record-control2.patch

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-03 00:02

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

Looks good, just two more requests out of me:
- "proccess" --> "process" in GuestApp_ControlRecord.
- I'm attaching statelogger_backdoor_def.h which contains a very
rudimentary record of this backdoor protocol. Could you incorporate it into
your patch, using its macros where appropriate?
File Added: statelogger_backdoor_def.h

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

Comment By: ven (ven9)
Date: 2008-09-01 02:58

Message:
Logged In: YES 
user_id=2082796
Originator: YES

Any comments?

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

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

[open-vm-tools-devel] [ open-vm-tools-Tracker-2064471 ] FEATURE:control vm recording by toolbox

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

Tracker item #2064471, was opened at 2008-08-21 03:41
Message generated for change (Comment added) made by adembo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2064471&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: ven (ven9)
Assigned to: Nobody/Anonymous (nobody)
Summary: FEATURE:control vm recording by toolbox

Initial Comment:
A patch that affects both vmware-toolbox and vmware-toolbox-cmd, adding start/stop recording functionalities for them. It adds a new GuestApp routine, through vmware backdoor, to do it, a new panel for toolbox and a new command for toolbox-cmd as UI.
This patch is based on 2008.08.08 release. I have already posted a version in devel mailing list, now I submit to tracker for simpler tracking.
Thanks to Adar's review. More comments are welcomed.

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

>Comment By: Adar Dembo (adembo)
Date: 2008-09-25 14:54

Message:
Thanks, Yiwen. I committed all of the patches.

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

Comment By: ven (ven9)
Date: 2008-09-24 02:18

Message:
Thanks for another reviewer.
The parameter name suggestion in GuestApp_ControlRecord is good for me. 
Root protection for record may be not necessary from my point of view. Do
we all agree with that?
I checked the mnemonics in toolbox. There is a conflict between r of
record tab and start button, which are all added by me. Now I change to s
of start and no conflict is seen.
Here is another patch for above changes.
File Added: 0001-Fix-according-to-Marcelo-s-comments.patch

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-22 18:39

Message:
Yiwen, here are some comments from Marcelo. He's having trouble using his
SF account so I'm posting this on his behalf; I think he's subscribed to
bug updates so feel free to respond.

Looks OK to me; I'd just choose a better name for the argument to
GuestApp_ControlRecord; what you'd passing is not really a "mode", but a
command
(i.e., "start recoding" and other commands defined in
statelogger_backdoor_def.h).

Also, the "root protection" in the Toolbox, for this particular case, is
pretty
useless, for reasons I guess we all know.

I'd also double-check if the mnemonics don't conflict with any existing
controls
in the UI.


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

Comment By: ven (ven9)
Date: 2008-09-17 19:35

Message:
Thank you for your kindness and patience:)
I am sorry for all the inconvenience. Since I started the patch before
2008.09.03, and I am new to git, I don't know an easy way to move previous
work along with its history. Hopefully there are no greate conflicts.

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-17 19:29

Message:
Don't worry, it was a learning exercise for me too; I learned about
git-merge and what a wonderful command it is.

Since you're working within a git repo, all you should need to do is 'git
pull', which will fetch the latest contents of the main open-vm-tools repo
(using git-fetch) and then merge them into your repo, accounting for any
local changes you've made that the main repo didn't have (using git-merge).
The merge will be automatic unless there are conflicts, at which point
you'll be prompted to make a three-way merge.

In this case, here's what I had to do:
- create a new branch named 'yiwen-patches' based on before 2008.09.03.
- switch to 'yiwen-patches'.
- apply your patchset (which commits them to that branch using the commit
details you provided in the patchset).
- switch back to the main branch.
- use git-merge to merge 'yiwen-patches' to the main branch. This brought
in all changes on 'yiwen-patches' which was just your patchset. There were
no conflicts, so it was all automatic.


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

Comment By: ven (ven9)
Date: 2008-09-17 19:24

Message:
Thank you for your kindness and patience:)
I am sorry for all the inconvenience. Since I started the patch before
2008.09.03, and I am new to git, I don't know an easy way to move previous
work along with its history. Hopefully there are no greate conflicts.

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-17 19:11

Message:
Yiwen, thanks for being so patient. I tried the latest patchset and was
able to get it to apply with a little bit of branching. In the future,
please make sure that the patches you send are based on the latest HEAD in
the git repo (yours were based on an older HEAD, before the 2008.09.03
refresh, which necessitated some merging on my part).

I'll forgo actually pushing your patches to the open-vm-tools repo until
we can get them reviewed by another reviewer; I'll try and round up another
member of our team.


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

Comment By: ven (ven9)
Date: 2008-09-17 00:16

Message:
I did another experiment. The failure of applying my patches should result
from that I created git control data at a cpdeeper level than the public
repository did. Sorry for the mistake.
I add prefix for file names in the new patches. I hope all issues
addressed have been resolved now.
File Added: newpatch.tar.gz

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

Comment By: ven (ven9)
Date: 2008-09-16 19:13

Message:
Thanks, Adar. Sorry for the late response due to a local festival.
I tested the patch files as follows:
1. Get an open-vm-tools tarball and extract. The source directory looks
like open-vm-tools-yyyy.mm.dd-build/;
2. Enter the directory, initialize a repository (git init, git add ., git
commit);
3. In the top level of source directory mentioned above, git am each patch
file, or use wildcard.
Since I stayed the top level of source directory, the file names in the
patch look fine to me. Perhaps your git profiles are in a higher level. If
it doesn't work, the file names may have to been modified explicitily.
I will fix other issues and submit them soon.

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-13 15:11

Message:
Thanks, Yiwhen. The screenshots look good; no problems there.

I'm still having some issues applying your patches, though:
- For each patch, make sure your e-mail address is listed. Some of them
show root@localhost.localdomain.
- For each patch, provide an explicit commit message title and details.
Some of the patches show "put your commit message title" as the message
title and "put your commit message details" in the details.
- Don't worry about "testing done" and "reviewers" if there aren't any for
a particular patch.
- Most importantly, all the file paths in your patches lack an
"open-vm-tools/" prefix. This means that when I try to apply them using
git-am, git can't find the files to patch. Could you either rebuild your
patches with the prefix in place in the file paths, or explain to me how I
should use git-am (or git-apply) so that I can connect the files in your
patches to my files?

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

Comment By: ven (ven9)
Date: 2008-09-11 05:39

Message:
Thank you for the comments. They sound reasonable. I have made adjust.
I have made ( and tested ) patch chain along with required screenshots.
They are packed in the attachment. The button layout may not be elegant for
various window size, though.
File Added: commit.tar.gz

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-11 01:22

Message:
I've looked at your second patch, and here is another round of comments:
- I'm trying to use git's workflow to incorporate your patches. To that
end, could you use git-format-patch to format your patches? That way I
should be able to use git-am to apply them easily (so make sure you can use
git-am locally to apply them).
- I'd like to see a screenshot of the new tab you've added to the gtk
toolbox. I'd also appreciate a screenshot of the error presented by
Toolsmain_MsgBox.
- In GuestApp_ControlRecord, refer to statelogger_backdoor_def.h without
the path. That way, we could move statelogger_backdoor_def.h to a new
location in the future without updating this comment.
- Don't bother calling out the isolation flag in RECORD_VMX_ERR. We cover
them exhaustively in the product manuals, and mentioning it by name in this
code will make it harder to change the name of the flag in the future.
- I have some cosmetic suggestions regarding the wording in
RECORD_VMX_ERR. Here's an alternative wording:
"Error, the Record/Replay control operation failed. This could be for one
of the following reasons:\n" \
"1. You are running an old version of a VMware product." \
"2. Your product has disabled these controls. To enable them, consult the
product documentation.\n\n" \
"3. You tried to start a recording while already recording.\n\n" \
"4. You tried to stop a recording while already not recording.\n\n"


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

Comment By: ven (ven9)
Date: 2008-09-09 23:04

Message:
Correct my typos and incorporate the new macros. Also add some
informational error message.
The new patch is applied after the first one.
File Added: record-control2.patch

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-03 00:02

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

Looks good, just two more requests out of me:
- "proccess" --> "process" in GuestApp_ControlRecord.
- I'm attaching statelogger_backdoor_def.h which contains a very
rudimentary record of this backdoor protocol. Could you incorporate it into
your patch, using its macros where appropriate?
File Added: statelogger_backdoor_def.h

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

Comment By: ven (ven9)
Date: 2008-09-01 02:58

Message:
Logged In: YES 
user_id=2082796
Originator: YES

Any comments?

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

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

Re: [open-vm-tools-devel] Experience of building open-vm-tools under Debian Etch

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

> This tripped me up, so I thought I'd share the problem and solution
> just in case someone follows in my footsteps or if the developers are
> interested.

Thanks for the feedback.

> I tracked the problem down to the module Makefiles declaring
> "HEADER_DIR = /lib/modules/$(VM_UNAME)/build/include". On the Debian
> systems that I have access to, build/ doesn't exist in
> /lib/modules/2.6.18-4-686. The kernel source Debian package installs
> under /usr/src/. I don't know if this is a peculiarity in the way I've
> configured or installed Debian or the packages, or if it's an incorrect
> assumption in the open-vm-tools build process.

On my Debian systems, /lib/modules/$(VM_UNAME)/build is typically a symlink to the kernel headers for that kernel. Usually you don't need the Debian kernel source packages; the Debian kernel header packages are sufficient for building out-of-tree modules. Those same header packages provide the build symlink.

For example, my Debian unstable machine has the linux-headers-2.6.26-1-amd64 package installed, which provides a symlink from /lib/modules/2.6.26-1-amd64/build to /usr/src/linux-headers-2.6.26-1-amd64.

> I tried configuring with either --includedir=/usr/src/linux-source-
> 2.6.18/include or HEADER_DIR="/usr/src/linux-source-2.6.18/include" and
> building without the symlink, but both used the standalone build system
> and failed as before. Maybe there's a correct way to configure
> HEADER_DIR?

I'm not sure if you'll be able to set it at configure time. But you can definitely specify HEADER_DIR at make time. Something like "make HEADER_DIR=/path/to/include/directory".

[open-vm-tools-devel] Experience of building open-vm-tools under Debian Etch

[Alan D. <Ala...@te...>]

This tripped me up, so I thought I'd share the problem and solution just in case someone follows in my footsteps or if the developers are interested.

I'm trying to build and install open-vm-tools on a Debian etch guest os (uname -a = 2.6.18-4-686 #1 SMP Mon Mar 26 17:17:36 UTC 2007 i686 GNU/Linux).

Initially the compilation failed when it got as far as compiling the modules, failing on the first module - vmmemctl. There were a lot of include file errors - redefinitions, undeclared stuff etc.

It had reported that it was "Using standalone build system." whereas installing VMware-tools on Debian usually reports "Using 2.6.x kernel build system."

I tracked the problem down to the module Makefiles declaring "HEADER_DIR = /lib/modules/$(VM_UNAME)/build/include". On the Debian systems that I have access to, build/ doesn't exist in /lib/modules/2.6.18-4-686. The kernel source Debian package installs under /usr/src/. I don't know if this is a peculiarity in the way I've configured or installed Debian or the packages, or if it's an incorrect assumption in the open-vm-tools build process.

Either way, I worked around it with a "ln -s /usr/src/linux-source-2.6.18/include /lib/modules/2.6.18-4-686/build/include" and it compiled fine.

I tried configuring with either --includedir=/usr/src/linux-source-2.6.18/include or HEADER_DIR="/usr/src/linux-source-2.6.18/include" and building without the symlink, but both used the standalone build system and failed as before. Maybe there's a correct way to configure HEADER_DIR?

Rather than installing a number of additional packages, I chose to configure with --without-x --without-dnet --without-icu.

Alan.


NOTICE & DISCLAIMER 
This email including attachments (this "Document") is confidential and may contain legally privileged information.  If you have received this Document in error please notify the sender immediately and delete this Document from your system without using, copying, disclosing or disseminating it or placing any reliance upon its contents.  We cannot accept liability for any breaches of confidence arising through use of this Document.

The information contained in this Document is provided solely for information purposes on an "as is" basis without warranty of any kind, either express or implied, including without limitation any implied warranty of satisfactory or merchantable quality, fitness for a particular purpose or freedom from error or infringement.  The user relies on the information contained herein, and its accuracy or otherwise, entirely at their own risk.

Any opinions expressed in this Document are those of the author and do not necessarily reflect the opinions of Telsis.  We will not accept responsibility for any commitments made by our employees outside the scope of our business.

[open-vm-tools-devel] [ open-vm-tools-Tracker-2064471 ] FEATURE:control vm recording by toolbox

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

Tracker item #2064471, was opened at 2008-08-21 18:41
Message generated for change (Comment added) made by ven9
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2064471&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: ven (ven9)
Assigned to: Nobody/Anonymous (nobody)
Summary: FEATURE:control vm recording by toolbox

Initial Comment:
A patch that affects both vmware-toolbox and vmware-toolbox-cmd, adding start/stop recording functionalities for them. It adds a new GuestApp routine, through vmware backdoor, to do it, a new panel for toolbox and a new command for toolbox-cmd as UI.
This patch is based on 2008.08.08 release. I have already posted a version in devel mailing list, now I submit to tracker for simpler tracking.
Thanks to Adar's review. More comments are welcomed.

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

>Comment By: ven (ven9)
Date: 2008-09-24 17:18

Message:
Thanks for another reviewer.
The parameter name suggestion in GuestApp_ControlRecord is good for me. 
Root protection for record may be not necessary from my point of view. Do
we all agree with that?
I checked the mnemonics in toolbox. There is a conflict between r of
record tab and start button, which are all added by me. Now I change to s
of start and no conflict is seen.
Here is another patch for above changes.
File Added: 0001-Fix-according-to-Marcelo-s-comments.patch

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-23 09:39

Message:
Yiwen, here are some comments from Marcelo. He's having trouble using his
SF account so I'm posting this on his behalf; I think he's subscribed to
bug updates so feel free to respond.

Looks OK to me; I'd just choose a better name for the argument to
GuestApp_ControlRecord; what you'd passing is not really a "mode", but a
command
(i.e., "start recoding" and other commands defined in
statelogger_backdoor_def.h).

Also, the "root protection" in the Toolbox, for this particular case, is
pretty
useless, for reasons I guess we all know.

I'd also double-check if the mnemonics don't conflict with any existing
controls
in the UI.


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

Comment By: ven (ven9)
Date: 2008-09-18 10:35

Message:
Thank you for your kindness and patience:)
I am sorry for all the inconvenience. Since I started the patch before
2008.09.03, and I am new to git, I don't know an easy way to move previous
work along with its history. Hopefully there are no greate conflicts.

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-18 10:29

Message:
Don't worry, it was a learning exercise for me too; I learned about
git-merge and what a wonderful command it is.

Since you're working within a git repo, all you should need to do is 'git
pull', which will fetch the latest contents of the main open-vm-tools repo
(using git-fetch) and then merge them into your repo, accounting for any
local changes you've made that the main repo didn't have (using git-merge).
The merge will be automatic unless there are conflicts, at which point
you'll be prompted to make a three-way merge.

In this case, here's what I had to do:
- create a new branch named 'yiwen-patches' based on before 2008.09.03.
- switch to 'yiwen-patches'.
- apply your patchset (which commits them to that branch using the commit
details you provided in the patchset).
- switch back to the main branch.
- use git-merge to merge 'yiwen-patches' to the main branch. This brought
in all changes on 'yiwen-patches' which was just your patchset. There were
no conflicts, so it was all automatic.


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

Comment By: ven (ven9)
Date: 2008-09-18 10:24

Message:
Thank you for your kindness and patience:)
I am sorry for all the inconvenience. Since I started the patch before
2008.09.03, and I am new to git, I don't know an easy way to move previous
work along with its history. Hopefully there are no greate conflicts.

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-18 10:11

Message:
Yiwen, thanks for being so patient. I tried the latest patchset and was
able to get it to apply with a little bit of branching. In the future,
please make sure that the patches you send are based on the latest HEAD in
the git repo (yours were based on an older HEAD, before the 2008.09.03
refresh, which necessitated some merging on my part).

I'll forgo actually pushing your patches to the open-vm-tools repo until
we can get them reviewed by another reviewer; I'll try and round up another
member of our team.


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

Comment By: ven (ven9)
Date: 2008-09-17 15:16

Message:
I did another experiment. The failure of applying my patches should result
from that I created git control data at a cpdeeper level than the public
repository did. Sorry for the mistake.
I add prefix for file names in the new patches. I hope all issues
addressed have been resolved now.
File Added: newpatch.tar.gz

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

Comment By: ven (ven9)
Date: 2008-09-17 10:13

Message:
Thanks, Adar. Sorry for the late response due to a local festival.
I tested the patch files as follows:
1. Get an open-vm-tools tarball and extract. The source directory looks
like open-vm-tools-yyyy.mm.dd-build/;
2. Enter the directory, initialize a repository (git init, git add ., git
commit);
3. In the top level of source directory mentioned above, git am each patch
file, or use wildcard.
Since I stayed the top level of source directory, the file names in the
patch look fine to me. Perhaps your git profiles are in a higher level. If
it doesn't work, the file names may have to been modified explicitily.
I will fix other issues and submit them soon.

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-14 06:11

Message:
Thanks, Yiwhen. The screenshots look good; no problems there.

I'm still having some issues applying your patches, though:
- For each patch, make sure your e-mail address is listed. Some of them
show root@localhost.localdomain.
- For each patch, provide an explicit commit message title and details.
Some of the patches show "put your commit message title" as the message
title and "put your commit message details" in the details.
- Don't worry about "testing done" and "reviewers" if there aren't any for
a particular patch.
- Most importantly, all the file paths in your patches lack an
"open-vm-tools/" prefix. This means that when I try to apply them using
git-am, git can't find the files to patch. Could you either rebuild your
patches with the prefix in place in the file paths, or explain to me how I
should use git-am (or git-apply) so that I can connect the files in your
patches to my files?

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

Comment By: ven (ven9)
Date: 2008-09-11 20:39

Message:
Thank you for the comments. They sound reasonable. I have made adjust.
I have made ( and tested ) patch chain along with required screenshots.
They are packed in the attachment. The button layout may not be elegant for
various window size, though.
File Added: commit.tar.gz

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-11 16:22

Message:
I've looked at your second patch, and here is another round of comments:
- I'm trying to use git's workflow to incorporate your patches. To that
end, could you use git-format-patch to format your patches? That way I
should be able to use git-am to apply them easily (so make sure you can use
git-am locally to apply them).
- I'd like to see a screenshot of the new tab you've added to the gtk
toolbox. I'd also appreciate a screenshot of the error presented by
Toolsmain_MsgBox.
- In GuestApp_ControlRecord, refer to statelogger_backdoor_def.h without
the path. That way, we could move statelogger_backdoor_def.h to a new
location in the future without updating this comment.
- Don't bother calling out the isolation flag in RECORD_VMX_ERR. We cover
them exhaustively in the product manuals, and mentioning it by name in this
code will make it harder to change the name of the flag in the future.
- I have some cosmetic suggestions regarding the wording in
RECORD_VMX_ERR. Here's an alternative wording:
"Error, the Record/Replay control operation failed. This could be for one
of the following reasons:\n" \
"1. You are running an old version of a VMware product." \
"2. Your product has disabled these controls. To enable them, consult the
product documentation.\n\n" \
"3. You tried to start a recording while already recording.\n\n" \
"4. You tried to stop a recording while already not recording.\n\n"


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

Comment By: ven (ven9)
Date: 2008-09-10 14:04

Message:
Correct my typos and incorporate the new macros. Also add some
informational error message.
The new patch is applied after the first one.
File Added: record-control2.patch

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-03 15:02

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

Looks good, just two more requests out of me:
- "proccess" --> "process" in GuestApp_ControlRecord.
- I'm attaching statelogger_backdoor_def.h which contains a very
rudimentary record of this backdoor protocol. Could you incorporate it into
your patch, using its macros where appropriate?
File Added: statelogger_backdoor_def.h

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

Comment By: ven (ven9)
Date: 2008-09-01 17:58

Message:
Logged In: YES 
user_id=2082796
Originator: YES

Any comments?

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

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

[open-vm-tools-devel] [ open-vm-tools-Tracker-2064471 ] FEATURE:control vm recording by toolbox

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

Tracker item #2064471, was opened at 2008-08-21 03:41
Message generated for change (Comment added) made by adembo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2064471&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: ven (ven9)
Assigned to: Nobody/Anonymous (nobody)
Summary: FEATURE:control vm recording by toolbox

Initial Comment:
A patch that affects both vmware-toolbox and vmware-toolbox-cmd, adding start/stop recording functionalities for them. It adds a new GuestApp routine, through vmware backdoor, to do it, a new panel for toolbox and a new command for toolbox-cmd as UI.
This patch is based on 2008.08.08 release. I have already posted a version in devel mailing list, now I submit to tracker for simpler tracking.
Thanks to Adar's review. More comments are welcomed.

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

>Comment By: Adar Dembo (adembo)
Date: 2008-09-22 18:39

Message:
Yiwen, here are some comments from Marcelo. He's having trouble using his
SF account so I'm posting this on his behalf; I think he's subscribed to
bug updates so feel free to respond.

Looks OK to me; I'd just choose a better name for the argument to
GuestApp_ControlRecord; what you'd passing is not really a "mode", but a
command
(i.e., "start recoding" and other commands defined in
statelogger_backdoor_def.h).

Also, the "root protection" in the Toolbox, for this particular case, is
pretty
useless, for reasons I guess we all know.

I'd also double-check if the mnemonics don't conflict with any existing
controls
in the UI.


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

Comment By: ven (ven9)
Date: 2008-09-17 19:35

Message:
Thank you for your kindness and patience:)
I am sorry for all the inconvenience. Since I started the patch before
2008.09.03, and I am new to git, I don't know an easy way to move previous
work along with its history. Hopefully there are no greate conflicts.

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-17 19:29

Message:
Don't worry, it was a learning exercise for me too; I learned about
git-merge and what a wonderful command it is.

Since you're working within a git repo, all you should need to do is 'git
pull', which will fetch the latest contents of the main open-vm-tools repo
(using git-fetch) and then merge them into your repo, accounting for any
local changes you've made that the main repo didn't have (using git-merge).
The merge will be automatic unless there are conflicts, at which point
you'll be prompted to make a three-way merge.

In this case, here's what I had to do:
- create a new branch named 'yiwen-patches' based on before 2008.09.03.
- switch to 'yiwen-patches'.
- apply your patchset (which commits them to that branch using the commit
details you provided in the patchset).
- switch back to the main branch.
- use git-merge to merge 'yiwen-patches' to the main branch. This brought
in all changes on 'yiwen-patches' which was just your patchset. There were
no conflicts, so it was all automatic.


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

Comment By: ven (ven9)
Date: 2008-09-17 19:24

Message:
Thank you for your kindness and patience:)
I am sorry for all the inconvenience. Since I started the patch before
2008.09.03, and I am new to git, I don't know an easy way to move previous
work along with its history. Hopefully there are no greate conflicts.

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-17 19:11

Message:
Yiwen, thanks for being so patient. I tried the latest patchset and was
able to get it to apply with a little bit of branching. In the future,
please make sure that the patches you send are based on the latest HEAD in
the git repo (yours were based on an older HEAD, before the 2008.09.03
refresh, which necessitated some merging on my part).

I'll forgo actually pushing your patches to the open-vm-tools repo until
we can get them reviewed by another reviewer; I'll try and round up another
member of our team.


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

Comment By: ven (ven9)
Date: 2008-09-17 00:16

Message:
I did another experiment. The failure of applying my patches should result
from that I created git control data at a cpdeeper level than the public
repository did. Sorry for the mistake.
I add prefix for file names in the new patches. I hope all issues
addressed have been resolved now.
File Added: newpatch.tar.gz

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

Comment By: ven (ven9)
Date: 2008-09-16 19:13

Message:
Thanks, Adar. Sorry for the late response due to a local festival.
I tested the patch files as follows:
1. Get an open-vm-tools tarball and extract. The source directory looks
like open-vm-tools-yyyy.mm.dd-build/;
2. Enter the directory, initialize a repository (git init, git add ., git
commit);
3. In the top level of source directory mentioned above, git am each patch
file, or use wildcard.
Since I stayed the top level of source directory, the file names in the
patch look fine to me. Perhaps your git profiles are in a higher level. If
it doesn't work, the file names may have to been modified explicitily.
I will fix other issues and submit them soon.

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-13 15:11

Message:
Thanks, Yiwhen. The screenshots look good; no problems there.

I'm still having some issues applying your patches, though:
- For each patch, make sure your e-mail address is listed. Some of them
show root@localhost.localdomain.
- For each patch, provide an explicit commit message title and details.
Some of the patches show "put your commit message title" as the message
title and "put your commit message details" in the details.
- Don't worry about "testing done" and "reviewers" if there aren't any for
a particular patch.
- Most importantly, all the file paths in your patches lack an
"open-vm-tools/" prefix. This means that when I try to apply them using
git-am, git can't find the files to patch. Could you either rebuild your
patches with the prefix in place in the file paths, or explain to me how I
should use git-am (or git-apply) so that I can connect the files in your
patches to my files?

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

Comment By: ven (ven9)
Date: 2008-09-11 05:39

Message:
Thank you for the comments. They sound reasonable. I have made adjust.
I have made ( and tested ) patch chain along with required screenshots.
They are packed in the attachment. The button layout may not be elegant for
various window size, though.
File Added: commit.tar.gz

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-11 01:22

Message:
I've looked at your second patch, and here is another round of comments:
- I'm trying to use git's workflow to incorporate your patches. To that
end, could you use git-format-patch to format your patches? That way I
should be able to use git-am to apply them easily (so make sure you can use
git-am locally to apply them).
- I'd like to see a screenshot of the new tab you've added to the gtk
toolbox. I'd also appreciate a screenshot of the error presented by
Toolsmain_MsgBox.
- In GuestApp_ControlRecord, refer to statelogger_backdoor_def.h without
the path. That way, we could move statelogger_backdoor_def.h to a new
location in the future without updating this comment.
- Don't bother calling out the isolation flag in RECORD_VMX_ERR. We cover
them exhaustively in the product manuals, and mentioning it by name in this
code will make it harder to change the name of the flag in the future.
- I have some cosmetic suggestions regarding the wording in
RECORD_VMX_ERR. Here's an alternative wording:
"Error, the Record/Replay control operation failed. This could be for one
of the following reasons:\n" \
"1. You are running an old version of a VMware product." \
"2. Your product has disabled these controls. To enable them, consult the
product documentation.\n\n" \
"3. You tried to start a recording while already recording.\n\n" \
"4. You tried to stop a recording while already not recording.\n\n"


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

Comment By: ven (ven9)
Date: 2008-09-09 23:04

Message:
Correct my typos and incorporate the new macros. Also add some
informational error message.
The new patch is applied after the first one.
File Added: record-control2.patch

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-03 00:02

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

Looks good, just two more requests out of me:
- "proccess" --> "process" in GuestApp_ControlRecord.
- I'm attaching statelogger_backdoor_def.h which contains a very
rudimentary record of this backdoor protocol. Could you incorporate it into
your patch, using its macros where appropriate?
File Added: statelogger_backdoor_def.h

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

Comment By: ven (ven9)
Date: 2008-09-01 02:58

Message:
Logged In: YES 
user_id=2082796
Originator: YES

Any comments?

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

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

[open-vm-tools-devel] [ open-vm-tools-Tracker-2064471 ] FEATURE:control vm recording by toolbox

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

Tracker item #2064471, was opened at 2008-08-21 18:41
Message generated for change (Comment added) made by ven9
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2064471&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: ven (ven9)
Assigned to: Nobody/Anonymous (nobody)
Summary: FEATURE:control vm recording by toolbox

Initial Comment:
A patch that affects both vmware-toolbox and vmware-toolbox-cmd, adding start/stop recording functionalities for them. It adds a new GuestApp routine, through vmware backdoor, to do it, a new panel for toolbox and a new command for toolbox-cmd as UI.
This patch is based on 2008.08.08 release. I have already posted a version in devel mailing list, now I submit to tracker for simpler tracking.
Thanks to Adar's review. More comments are welcomed.

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

>Comment By: ven (ven9)
Date: 2008-09-18 10:35

Message:
Thank you for your kindness and patience:)
I am sorry for all the inconvenience. Since I started the patch before
2008.09.03, and I am new to git, I don't know an easy way to move previous
work along with its history. Hopefully there are no greate conflicts.

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-18 10:29

Message:
Don't worry, it was a learning exercise for me too; I learned about
git-merge and what a wonderful command it is.

Since you're working within a git repo, all you should need to do is 'git
pull', which will fetch the latest contents of the main open-vm-tools repo
(using git-fetch) and then merge them into your repo, accounting for any
local changes you've made that the main repo didn't have (using git-merge).
The merge will be automatic unless there are conflicts, at which point
you'll be prompted to make a three-way merge.

In this case, here's what I had to do:
- create a new branch named 'yiwen-patches' based on before 2008.09.03.
- switch to 'yiwen-patches'.
- apply your patchset (which commits them to that branch using the commit
details you provided in the patchset).
- switch back to the main branch.
- use git-merge to merge 'yiwen-patches' to the main branch. This brought
in all changes on 'yiwen-patches' which was just your patchset. There were
no conflicts, so it was all automatic.


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

Comment By: ven (ven9)
Date: 2008-09-18 10:24

Message:
Thank you for your kindness and patience:)
I am sorry for all the inconvenience. Since I started the patch before
2008.09.03, and I am new to git, I don't know an easy way to move previous
work along with its history. Hopefully there are no greate conflicts.

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-18 10:11

Message:
Yiwen, thanks for being so patient. I tried the latest patchset and was
able to get it to apply with a little bit of branching. In the future,
please make sure that the patches you send are based on the latest HEAD in
the git repo (yours were based on an older HEAD, before the 2008.09.03
refresh, which necessitated some merging on my part).

I'll forgo actually pushing your patches to the open-vm-tools repo until
we can get them reviewed by another reviewer; I'll try and round up another
member of our team.


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

Comment By: ven (ven9)
Date: 2008-09-17 15:16

Message:
I did another experiment. The failure of applying my patches should result
from that I created git control data at a cpdeeper level than the public
repository did. Sorry for the mistake.
I add prefix for file names in the new patches. I hope all issues
addressed have been resolved now.
File Added: newpatch.tar.gz

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

Comment By: ven (ven9)
Date: 2008-09-17 10:13

Message:
Thanks, Adar. Sorry for the late response due to a local festival.
I tested the patch files as follows:
1. Get an open-vm-tools tarball and extract. The source directory looks
like open-vm-tools-yyyy.mm.dd-build/;
2. Enter the directory, initialize a repository (git init, git add ., git
commit);
3. In the top level of source directory mentioned above, git am each patch
file, or use wildcard.
Since I stayed the top level of source directory, the file names in the
patch look fine to me. Perhaps your git profiles are in a higher level. If
it doesn't work, the file names may have to been modified explicitily.
I will fix other issues and submit them soon.

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-14 06:11

Message:
Thanks, Yiwhen. The screenshots look good; no problems there.

I'm still having some issues applying your patches, though:
- For each patch, make sure your e-mail address is listed. Some of them
show root@localhost.localdomain.
- For each patch, provide an explicit commit message title and details.
Some of the patches show "put your commit message title" as the message
title and "put your commit message details" in the details.
- Don't worry about "testing done" and "reviewers" if there aren't any for
a particular patch.
- Most importantly, all the file paths in your patches lack an
"open-vm-tools/" prefix. This means that when I try to apply them using
git-am, git can't find the files to patch. Could you either rebuild your
patches with the prefix in place in the file paths, or explain to me how I
should use git-am (or git-apply) so that I can connect the files in your
patches to my files?

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

Comment By: ven (ven9)
Date: 2008-09-11 20:39

Message:
Thank you for the comments. They sound reasonable. I have made adjust.
I have made ( and tested ) patch chain along with required screenshots.
They are packed in the attachment. The button layout may not be elegant for
various window size, though.
File Added: commit.tar.gz

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-11 16:22

Message:
I've looked at your second patch, and here is another round of comments:
- I'm trying to use git's workflow to incorporate your patches. To that
end, could you use git-format-patch to format your patches? That way I
should be able to use git-am to apply them easily (so make sure you can use
git-am locally to apply them).
- I'd like to see a screenshot of the new tab you've added to the gtk
toolbox. I'd also appreciate a screenshot of the error presented by
Toolsmain_MsgBox.
- In GuestApp_ControlRecord, refer to statelogger_backdoor_def.h without
the path. That way, we could move statelogger_backdoor_def.h to a new
location in the future without updating this comment.
- Don't bother calling out the isolation flag in RECORD_VMX_ERR. We cover
them exhaustively in the product manuals, and mentioning it by name in this
code will make it harder to change the name of the flag in the future.
- I have some cosmetic suggestions regarding the wording in
RECORD_VMX_ERR. Here's an alternative wording:
"Error, the Record/Replay control operation failed. This could be for one
of the following reasons:\n" \
"1. You are running an old version of a VMware product." \
"2. Your product has disabled these controls. To enable them, consult the
product documentation.\n\n" \
"3. You tried to start a recording while already recording.\n\n" \
"4. You tried to stop a recording while already not recording.\n\n"


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

Comment By: ven (ven9)
Date: 2008-09-10 14:04

Message:
Correct my typos and incorporate the new macros. Also add some
informational error message.
The new patch is applied after the first one.
File Added: record-control2.patch

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-03 15:02

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

Looks good, just two more requests out of me:
- "proccess" --> "process" in GuestApp_ControlRecord.
- I'm attaching statelogger_backdoor_def.h which contains a very
rudimentary record of this backdoor protocol. Could you incorporate it into
your patch, using its macros where appropriate?
File Added: statelogger_backdoor_def.h

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

Comment By: ven (ven9)
Date: 2008-09-01 17:58

Message:
Logged In: YES 
user_id=2082796
Originator: YES

Any comments?

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

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

[open-vm-tools-devel] [ open-vm-tools-Tracker-2064471 ] FEATURE:control vm recording by toolbox

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

Tracker item #2064471, was opened at 2008-08-21 03:41
Message generated for change (Comment added) made by adembo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2064471&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: ven (ven9)
Assigned to: Nobody/Anonymous (nobody)
Summary: FEATURE:control vm recording by toolbox

Initial Comment:
A patch that affects both vmware-toolbox and vmware-toolbox-cmd, adding start/stop recording functionalities for them. It adds a new GuestApp routine, through vmware backdoor, to do it, a new panel for toolbox and a new command for toolbox-cmd as UI.
This patch is based on 2008.08.08 release. I have already posted a version in devel mailing list, now I submit to tracker for simpler tracking.
Thanks to Adar's review. More comments are welcomed.

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

>Comment By: Adar Dembo (adembo)
Date: 2008-09-17 19:29

Message:
Don't worry, it was a learning exercise for me too; I learned about
git-merge and what a wonderful command it is.

Since you're working within a git repo, all you should need to do is 'git
pull', which will fetch the latest contents of the main open-vm-tools repo
(using git-fetch) and then merge them into your repo, accounting for any
local changes you've made that the main repo didn't have (using git-merge).
The merge will be automatic unless there are conflicts, at which point
you'll be prompted to make a three-way merge.

In this case, here's what I had to do:
- create a new branch named 'yiwen-patches' based on before 2008.09.03.
- switch to 'yiwen-patches'.
- apply your patchset (which commits them to that branch using the commit
details you provided in the patchset).
- switch back to the main branch.
- use git-merge to merge 'yiwen-patches' to the main branch. This brought
in all changes on 'yiwen-patches' which was just your patchset. There were
no conflicts, so it was all automatic.


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

Comment By: ven (ven9)
Date: 2008-09-17 19:24

Message:
Thank you for your kindness and patience:)
I am sorry for all the inconvenience. Since I started the patch before
2008.09.03, and I am new to git, I don't know an easy way to move previous
work along with its history. Hopefully there are no greate conflicts.

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-17 19:11

Message:
Yiwen, thanks for being so patient. I tried the latest patchset and was
able to get it to apply with a little bit of branching. In the future,
please make sure that the patches you send are based on the latest HEAD in
the git repo (yours were based on an older HEAD, before the 2008.09.03
refresh, which necessitated some merging on my part).

I'll forgo actually pushing your patches to the open-vm-tools repo until
we can get them reviewed by another reviewer; I'll try and round up another
member of our team.


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

Comment By: ven (ven9)
Date: 2008-09-17 00:16

Message:
I did another experiment. The failure of applying my patches should result
from that I created git control data at a cpdeeper level than the public
repository did. Sorry for the mistake.
I add prefix for file names in the new patches. I hope all issues
addressed have been resolved now.
File Added: newpatch.tar.gz

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

Comment By: ven (ven9)
Date: 2008-09-16 19:13

Message:
Thanks, Adar. Sorry for the late response due to a local festival.
I tested the patch files as follows:
1. Get an open-vm-tools tarball and extract. The source directory looks
like open-vm-tools-yyyy.mm.dd-build/;
2. Enter the directory, initialize a repository (git init, git add ., git
commit);
3. In the top level of source directory mentioned above, git am each patch
file, or use wildcard.
Since I stayed the top level of source directory, the file names in the
patch look fine to me. Perhaps your git profiles are in a higher level. If
it doesn't work, the file names may have to been modified explicitily.
I will fix other issues and submit them soon.

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-13 15:11

Message:
Thanks, Yiwhen. The screenshots look good; no problems there.

I'm still having some issues applying your patches, though:
- For each patch, make sure your e-mail address is listed. Some of them
show root@localhost.localdomain.
- For each patch, provide an explicit commit message title and details.
Some of the patches show "put your commit message title" as the message
title and "put your commit message details" in the details.
- Don't worry about "testing done" and "reviewers" if there aren't any for
a particular patch.
- Most importantly, all the file paths in your patches lack an
"open-vm-tools/" prefix. This means that when I try to apply them using
git-am, git can't find the files to patch. Could you either rebuild your
patches with the prefix in place in the file paths, or explain to me how I
should use git-am (or git-apply) so that I can connect the files in your
patches to my files?

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

Comment By: ven (ven9)
Date: 2008-09-11 05:39

Message:
Thank you for the comments. They sound reasonable. I have made adjust.
I have made ( and tested ) patch chain along with required screenshots.
They are packed in the attachment. The button layout may not be elegant for
various window size, though.
File Added: commit.tar.gz

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-11 01:22

Message:
I've looked at your second patch, and here is another round of comments:
- I'm trying to use git's workflow to incorporate your patches. To that
end, could you use git-format-patch to format your patches? That way I
should be able to use git-am to apply them easily (so make sure you can use
git-am locally to apply them).
- I'd like to see a screenshot of the new tab you've added to the gtk
toolbox. I'd also appreciate a screenshot of the error presented by
Toolsmain_MsgBox.
- In GuestApp_ControlRecord, refer to statelogger_backdoor_def.h without
the path. That way, we could move statelogger_backdoor_def.h to a new
location in the future without updating this comment.
- Don't bother calling out the isolation flag in RECORD_VMX_ERR. We cover
them exhaustively in the product manuals, and mentioning it by name in this
code will make it harder to change the name of the flag in the future.
- I have some cosmetic suggestions regarding the wording in
RECORD_VMX_ERR. Here's an alternative wording:
"Error, the Record/Replay control operation failed. This could be for one
of the following reasons:\n" \
"1. You are running an old version of a VMware product." \
"2. Your product has disabled these controls. To enable them, consult the
product documentation.\n\n" \
"3. You tried to start a recording while already recording.\n\n" \
"4. You tried to stop a recording while already not recording.\n\n"


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

Comment By: ven (ven9)
Date: 2008-09-09 23:04

Message:
Correct my typos and incorporate the new macros. Also add some
informational error message.
The new patch is applied after the first one.
File Added: record-control2.patch

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-03 00:02

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

Looks good, just two more requests out of me:
- "proccess" --> "process" in GuestApp_ControlRecord.
- I'm attaching statelogger_backdoor_def.h which contains a very
rudimentary record of this backdoor protocol. Could you incorporate it into
your patch, using its macros where appropriate?
File Added: statelogger_backdoor_def.h

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

Comment By: ven (ven9)
Date: 2008-09-01 02:58

Message:
Logged In: YES 
user_id=2082796
Originator: YES

Any comments?

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

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

[open-vm-tools-devel] [ open-vm-tools-Tracker-2064471 ] FEATURE:control vm recording by toolbox

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

Tracker item #2064471, was opened at 2008-08-21 18:41
Message generated for change (Comment added) made by ven9
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2064471&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: ven (ven9)
Assigned to: Nobody/Anonymous (nobody)
Summary: FEATURE:control vm recording by toolbox

Initial Comment:
A patch that affects both vmware-toolbox and vmware-toolbox-cmd, adding start/stop recording functionalities for them. It adds a new GuestApp routine, through vmware backdoor, to do it, a new panel for toolbox and a new command for toolbox-cmd as UI.
This patch is based on 2008.08.08 release. I have already posted a version in devel mailing list, now I submit to tracker for simpler tracking.
Thanks to Adar's review. More comments are welcomed.

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

>Comment By: ven (ven9)
Date: 2008-09-18 10:24

Message:
Thank you for your kindness and patience:)
I am sorry for all the inconvenience. Since I started the patch before
2008.09.03, and I am new to git, I don't know an easy way to move previous
work along with its history. Hopefully there are no greate conflicts.

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-18 10:11

Message:
Yiwen, thanks for being so patient. I tried the latest patchset and was
able to get it to apply with a little bit of branching. In the future,
please make sure that the patches you send are based on the latest HEAD in
the git repo (yours were based on an older HEAD, before the 2008.09.03
refresh, which necessitated some merging on my part).

I'll forgo actually pushing your patches to the open-vm-tools repo until
we can get them reviewed by another reviewer; I'll try and round up another
member of our team.


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

Comment By: ven (ven9)
Date: 2008-09-17 15:16

Message:
I did another experiment. The failure of applying my patches should result
from that I created git control data at a cpdeeper level than the public
repository did. Sorry for the mistake.
I add prefix for file names in the new patches. I hope all issues
addressed have been resolved now.
File Added: newpatch.tar.gz

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

Comment By: ven (ven9)
Date: 2008-09-17 10:13

Message:
Thanks, Adar. Sorry for the late response due to a local festival.
I tested the patch files as follows:
1. Get an open-vm-tools tarball and extract. The source directory looks
like open-vm-tools-yyyy.mm.dd-build/;
2. Enter the directory, initialize a repository (git init, git add ., git
commit);
3. In the top level of source directory mentioned above, git am each patch
file, or use wildcard.
Since I stayed the top level of source directory, the file names in the
patch look fine to me. Perhaps your git profiles are in a higher level. If
it doesn't work, the file names may have to been modified explicitily.
I will fix other issues and submit them soon.

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-14 06:11

Message:
Thanks, Yiwhen. The screenshots look good; no problems there.

I'm still having some issues applying your patches, though:
- For each patch, make sure your e-mail address is listed. Some of them
show root@localhost.localdomain.
- For each patch, provide an explicit commit message title and details.
Some of the patches show "put your commit message title" as the message
title and "put your commit message details" in the details.
- Don't worry about "testing done" and "reviewers" if there aren't any for
a particular patch.
- Most importantly, all the file paths in your patches lack an
"open-vm-tools/" prefix. This means that when I try to apply them using
git-am, git can't find the files to patch. Could you either rebuild your
patches with the prefix in place in the file paths, or explain to me how I
should use git-am (or git-apply) so that I can connect the files in your
patches to my files?

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

Comment By: ven (ven9)
Date: 2008-09-11 20:39

Message:
Thank you for the comments. They sound reasonable. I have made adjust.
I have made ( and tested ) patch chain along with required screenshots.
They are packed in the attachment. The button layout may not be elegant for
various window size, though.
File Added: commit.tar.gz

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-11 16:22

Message:
I've looked at your second patch, and here is another round of comments:
- I'm trying to use git's workflow to incorporate your patches. To that
end, could you use git-format-patch to format your patches? That way I
should be able to use git-am to apply them easily (so make sure you can use
git-am locally to apply them).
- I'd like to see a screenshot of the new tab you've added to the gtk
toolbox. I'd also appreciate a screenshot of the error presented by
Toolsmain_MsgBox.
- In GuestApp_ControlRecord, refer to statelogger_backdoor_def.h without
the path. That way, we could move statelogger_backdoor_def.h to a new
location in the future without updating this comment.
- Don't bother calling out the isolation flag in RECORD_VMX_ERR. We cover
them exhaustively in the product manuals, and mentioning it by name in this
code will make it harder to change the name of the flag in the future.
- I have some cosmetic suggestions regarding the wording in
RECORD_VMX_ERR. Here's an alternative wording:
"Error, the Record/Replay control operation failed. This could be for one
of the following reasons:\n" \
"1. You are running an old version of a VMware product." \
"2. Your product has disabled these controls. To enable them, consult the
product documentation.\n\n" \
"3. You tried to start a recording while already recording.\n\n" \
"4. You tried to stop a recording while already not recording.\n\n"


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

Comment By: ven (ven9)
Date: 2008-09-10 14:04

Message:
Correct my typos and incorporate the new macros. Also add some
informational error message.
The new patch is applied after the first one.
File Added: record-control2.patch

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-03 15:02

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

Looks good, just two more requests out of me:
- "proccess" --> "process" in GuestApp_ControlRecord.
- I'm attaching statelogger_backdoor_def.h which contains a very
rudimentary record of this backdoor protocol. Could you incorporate it into
your patch, using its macros where appropriate?
File Added: statelogger_backdoor_def.h

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

Comment By: ven (ven9)
Date: 2008-09-01 17:58

Message:
Logged In: YES 
user_id=2082796
Originator: YES

Any comments?

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

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

[open-vm-tools-devel] [ open-vm-tools-Tracker-2064471 ] FEATURE:control vm recording by toolbox

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

Tracker item #2064471, was opened at 2008-08-21 03:41
Message generated for change (Comment added) made by adembo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2064471&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: ven (ven9)
Assigned to: Nobody/Anonymous (nobody)
Summary: FEATURE:control vm recording by toolbox

Initial Comment:
A patch that affects both vmware-toolbox and vmware-toolbox-cmd, adding start/stop recording functionalities for them. It adds a new GuestApp routine, through vmware backdoor, to do it, a new panel for toolbox and a new command for toolbox-cmd as UI.
This patch is based on 2008.08.08 release. I have already posted a version in devel mailing list, now I submit to tracker for simpler tracking.
Thanks to Adar's review. More comments are welcomed.

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

>Comment By: Adar Dembo (adembo)
Date: 2008-09-17 19:11

Message:
Yiwen, thanks for being so patient. I tried the latest patchset and was
able to get it to apply with a little bit of branching. In the future,
please make sure that the patches you send are based on the latest HEAD in
the git repo (yours were based on an older HEAD, before the 2008.09.03
refresh, which necessitated some merging on my part).

I'll forgo actually pushing your patches to the open-vm-tools repo until
we can get them reviewed by another reviewer; I'll try and round up another
member of our team.


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

Comment By: ven (ven9)
Date: 2008-09-17 00:16

Message:
I did another experiment. The failure of applying my patches should result
from that I created git control data at a cpdeeper level than the public
repository did. Sorry for the mistake.
I add prefix for file names in the new patches. I hope all issues
addressed have been resolved now.
File Added: newpatch.tar.gz

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

Comment By: ven (ven9)
Date: 2008-09-16 19:13

Message:
Thanks, Adar. Sorry for the late response due to a local festival.
I tested the patch files as follows:
1. Get an open-vm-tools tarball and extract. The source directory looks
like open-vm-tools-yyyy.mm.dd-build/;
2. Enter the directory, initialize a repository (git init, git add ., git
commit);
3. In the top level of source directory mentioned above, git am each patch
file, or use wildcard.
Since I stayed the top level of source directory, the file names in the
patch look fine to me. Perhaps your git profiles are in a higher level. If
it doesn't work, the file names may have to been modified explicitily.
I will fix other issues and submit them soon.

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-13 15:11

Message:
Thanks, Yiwhen. The screenshots look good; no problems there.

I'm still having some issues applying your patches, though:
- For each patch, make sure your e-mail address is listed. Some of them
show root@localhost.localdomain.
- For each patch, provide an explicit commit message title and details.
Some of the patches show "put your commit message title" as the message
title and "put your commit message details" in the details.
- Don't worry about "testing done" and "reviewers" if there aren't any for
a particular patch.
- Most importantly, all the file paths in your patches lack an
"open-vm-tools/" prefix. This means that when I try to apply them using
git-am, git can't find the files to patch. Could you either rebuild your
patches with the prefix in place in the file paths, or explain to me how I
should use git-am (or git-apply) so that I can connect the files in your
patches to my files?

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

Comment By: ven (ven9)
Date: 2008-09-11 05:39

Message:
Thank you for the comments. They sound reasonable. I have made adjust.
I have made ( and tested ) patch chain along with required screenshots.
They are packed in the attachment. The button layout may not be elegant for
various window size, though.
File Added: commit.tar.gz

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-11 01:22

Message:
I've looked at your second patch, and here is another round of comments:
- I'm trying to use git's workflow to incorporate your patches. To that
end, could you use git-format-patch to format your patches? That way I
should be able to use git-am to apply them easily (so make sure you can use
git-am locally to apply them).
- I'd like to see a screenshot of the new tab you've added to the gtk
toolbox. I'd also appreciate a screenshot of the error presented by
Toolsmain_MsgBox.
- In GuestApp_ControlRecord, refer to statelogger_backdoor_def.h without
the path. That way, we could move statelogger_backdoor_def.h to a new
location in the future without updating this comment.
- Don't bother calling out the isolation flag in RECORD_VMX_ERR. We cover
them exhaustively in the product manuals, and mentioning it by name in this
code will make it harder to change the name of the flag in the future.
- I have some cosmetic suggestions regarding the wording in
RECORD_VMX_ERR. Here's an alternative wording:
"Error, the Record/Replay control operation failed. This could be for one
of the following reasons:\n" \
"1. You are running an old version of a VMware product." \
"2. Your product has disabled these controls. To enable them, consult the
product documentation.\n\n" \
"3. You tried to start a recording while already recording.\n\n" \
"4. You tried to stop a recording while already not recording.\n\n"


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

Comment By: ven (ven9)
Date: 2008-09-09 23:04

Message:
Correct my typos and incorporate the new macros. Also add some
informational error message.
The new patch is applied after the first one.
File Added: record-control2.patch

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-03 00:02

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

Looks good, just two more requests out of me:
- "proccess" --> "process" in GuestApp_ControlRecord.
- I'm attaching statelogger_backdoor_def.h which contains a very
rudimentary record of this backdoor protocol. Could you incorporate it into
your patch, using its macros where appropriate?
File Added: statelogger_backdoor_def.h

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

Comment By: ven (ven9)
Date: 2008-09-01 02:58

Message:
Logged In: YES 
user_id=2082796
Originator: YES

Any comments?

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

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

[open-vm-tools-devel] [ open-vm-tools-Tracker-2064471 ] FEATURE:control vm recording by toolbox

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

Tracker item #2064471, was opened at 2008-08-21 18:41
Message generated for change (Comment added) made by ven9
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2064471&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: ven (ven9)
Assigned to: Nobody/Anonymous (nobody)
Summary: FEATURE:control vm recording by toolbox

Initial Comment:
A patch that affects both vmware-toolbox and vmware-toolbox-cmd, adding start/stop recording functionalities for them. It adds a new GuestApp routine, through vmware backdoor, to do it, a new panel for toolbox and a new command for toolbox-cmd as UI.
This patch is based on 2008.08.08 release. I have already posted a version in devel mailing list, now I submit to tracker for simpler tracking.
Thanks to Adar's review. More comments are welcomed.

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

>Comment By: ven (ven9)
Date: 2008-09-17 15:16

Message:
I did another experiment. The failure of applying my patches should result
from that I created git control data at a cpdeeper level than the public
repository did. Sorry for the mistake.
I add prefix for file names in the new patches. I hope all issues
addressed have been resolved now.
File Added: newpatch.tar.gz

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

Comment By: ven (ven9)
Date: 2008-09-17 10:13

Message:
Thanks, Adar. Sorry for the late response due to a local festival.
I tested the patch files as follows:
1. Get an open-vm-tools tarball and extract. The source directory looks
like open-vm-tools-yyyy.mm.dd-build/;
2. Enter the directory, initialize a repository (git init, git add ., git
commit);
3. In the top level of source directory mentioned above, git am each patch
file, or use wildcard.
Since I stayed the top level of source directory, the file names in the
patch look fine to me. Perhaps your git profiles are in a higher level. If
it doesn't work, the file names may have to been modified explicitily.
I will fix other issues and submit them soon.

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-14 06:11

Message:
Thanks, Yiwhen. The screenshots look good; no problems there.

I'm still having some issues applying your patches, though:
- For each patch, make sure your e-mail address is listed. Some of them
show root@localhost.localdomain.
- For each patch, provide an explicit commit message title and details.
Some of the patches show "put your commit message title" as the message
title and "put your commit message details" in the details.
- Don't worry about "testing done" and "reviewers" if there aren't any for
a particular patch.
- Most importantly, all the file paths in your patches lack an
"open-vm-tools/" prefix. This means that when I try to apply them using
git-am, git can't find the files to patch. Could you either rebuild your
patches with the prefix in place in the file paths, or explain to me how I
should use git-am (or git-apply) so that I can connect the files in your
patches to my files?

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

Comment By: ven (ven9)
Date: 2008-09-11 20:39

Message:
Thank you for the comments. They sound reasonable. I have made adjust.
I have made ( and tested ) patch chain along with required screenshots.
They are packed in the attachment. The button layout may not be elegant for
various window size, though.
File Added: commit.tar.gz

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-11 16:22

Message:
I've looked at your second patch, and here is another round of comments:
- I'm trying to use git's workflow to incorporate your patches. To that
end, could you use git-format-patch to format your patches? That way I
should be able to use git-am to apply them easily (so make sure you can use
git-am locally to apply them).
- I'd like to see a screenshot of the new tab you've added to the gtk
toolbox. I'd also appreciate a screenshot of the error presented by
Toolsmain_MsgBox.
- In GuestApp_ControlRecord, refer to statelogger_backdoor_def.h without
the path. That way, we could move statelogger_backdoor_def.h to a new
location in the future without updating this comment.
- Don't bother calling out the isolation flag in RECORD_VMX_ERR. We cover
them exhaustively in the product manuals, and mentioning it by name in this
code will make it harder to change the name of the flag in the future.
- I have some cosmetic suggestions regarding the wording in
RECORD_VMX_ERR. Here's an alternative wording:
"Error, the Record/Replay control operation failed. This could be for one
of the following reasons:\n" \
"1. You are running an old version of a VMware product." \
"2. Your product has disabled these controls. To enable them, consult the
product documentation.\n\n" \
"3. You tried to start a recording while already recording.\n\n" \
"4. You tried to stop a recording while already not recording.\n\n"


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

Comment By: ven (ven9)
Date: 2008-09-10 14:04

Message:
Correct my typos and incorporate the new macros. Also add some
informational error message.
The new patch is applied after the first one.
File Added: record-control2.patch

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-03 15:02

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

Looks good, just two more requests out of me:
- "proccess" --> "process" in GuestApp_ControlRecord.
- I'm attaching statelogger_backdoor_def.h which contains a very
rudimentary record of this backdoor protocol. Could you incorporate it into
your patch, using its macros where appropriate?
File Added: statelogger_backdoor_def.h

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

Comment By: ven (ven9)
Date: 2008-09-01 17:58

Message:
Logged In: YES 
user_id=2082796
Originator: YES

Any comments?

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

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

[open-vm-tools-devel] [ open-vm-tools-Tracker-2064471 ] FEATURE:control vm recording by toolbox

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

Tracker item #2064471, was opened at 2008-08-21 18:41
Message generated for change (Comment added) made by ven9
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2064471&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: ven (ven9)
Assigned to: Nobody/Anonymous (nobody)
Summary: FEATURE:control vm recording by toolbox

Initial Comment:
A patch that affects both vmware-toolbox and vmware-toolbox-cmd, adding start/stop recording functionalities for them. It adds a new GuestApp routine, through vmware backdoor, to do it, a new panel for toolbox and a new command for toolbox-cmd as UI.
This patch is based on 2008.08.08 release. I have already posted a version in devel mailing list, now I submit to tracker for simpler tracking.
Thanks to Adar's review. More comments are welcomed.

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

>Comment By: ven (ven9)
Date: 2008-09-17 10:13

Message:
Thanks, Adar. Sorry for the late response due to a local festival.
I tested the patch files as follows:
1. Get an open-vm-tools tarball and extract. The source directory looks
like open-vm-tools-yyyy.mm.dd-build/;
2. Enter the directory, initialize a repository (git init, git add ., git
commit);
3. In the top level of source directory mentioned above, git am each patch
file, or use wildcard.
Since I stayed the top level of source directory, the file names in the
patch look fine to me. Perhaps your git profiles are in a higher level. If
it doesn't work, the file names may have to been modified explicitily.
I will fix other issues and submit them soon.

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-14 06:11

Message:
Thanks, Yiwhen. The screenshots look good; no problems there.

I'm still having some issues applying your patches, though:
- For each patch, make sure your e-mail address is listed. Some of them
show root@localhost.localdomain.
- For each patch, provide an explicit commit message title and details.
Some of the patches show "put your commit message title" as the message
title and "put your commit message details" in the details.
- Don't worry about "testing done" and "reviewers" if there aren't any for
a particular patch.
- Most importantly, all the file paths in your patches lack an
"open-vm-tools/" prefix. This means that when I try to apply them using
git-am, git can't find the files to patch. Could you either rebuild your
patches with the prefix in place in the file paths, or explain to me how I
should use git-am (or git-apply) so that I can connect the files in your
patches to my files?

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

Comment By: ven (ven9)
Date: 2008-09-11 20:39

Message:
Thank you for the comments. They sound reasonable. I have made adjust.
I have made ( and tested ) patch chain along with required screenshots.
They are packed in the attachment. The button layout may not be elegant for
various window size, though.
File Added: commit.tar.gz

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-11 16:22

Message:
I've looked at your second patch, and here is another round of comments:
- I'm trying to use git's workflow to incorporate your patches. To that
end, could you use git-format-patch to format your patches? That way I
should be able to use git-am to apply them easily (so make sure you can use
git-am locally to apply them).
- I'd like to see a screenshot of the new tab you've added to the gtk
toolbox. I'd also appreciate a screenshot of the error presented by
Toolsmain_MsgBox.
- In GuestApp_ControlRecord, refer to statelogger_backdoor_def.h without
the path. That way, we could move statelogger_backdoor_def.h to a new
location in the future without updating this comment.
- Don't bother calling out the isolation flag in RECORD_VMX_ERR. We cover
them exhaustively in the product manuals, and mentioning it by name in this
code will make it harder to change the name of the flag in the future.
- I have some cosmetic suggestions regarding the wording in
RECORD_VMX_ERR. Here's an alternative wording:
"Error, the Record/Replay control operation failed. This could be for one
of the following reasons:\n" \
"1. You are running an old version of a VMware product." \
"2. Your product has disabled these controls. To enable them, consult the
product documentation.\n\n" \
"3. You tried to start a recording while already recording.\n\n" \
"4. You tried to stop a recording while already not recording.\n\n"


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

Comment By: ven (ven9)
Date: 2008-09-10 14:04

Message:
Correct my typos and incorporate the new macros. Also add some
informational error message.
The new patch is applied after the first one.
File Added: record-control2.patch

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-03 15:02

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

Looks good, just two more requests out of me:
- "proccess" --> "process" in GuestApp_ControlRecord.
- I'm attaching statelogger_backdoor_def.h which contains a very
rudimentary record of this backdoor protocol. Could you incorporate it into
your patch, using its macros where appropriate?
File Added: statelogger_backdoor_def.h

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

Comment By: ven (ven9)
Date: 2008-09-01 17:58

Message:
Logged In: YES 
user_id=2082796
Originator: YES

Any comments?

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

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

[open-vm-tools-devel] [ open-vm-tools-Tracker-2064471 ] FEATURE:control vm recording by toolbox

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

Tracker item #2064471, was opened at 2008-08-21 03:41
Message generated for change (Comment added) made by adembo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2064471&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: ven (ven9)
Assigned to: Nobody/Anonymous (nobody)
Summary: FEATURE:control vm recording by toolbox

Initial Comment:
A patch that affects both vmware-toolbox and vmware-toolbox-cmd, adding start/stop recording functionalities for them. It adds a new GuestApp routine, through vmware backdoor, to do it, a new panel for toolbox and a new command for toolbox-cmd as UI.
This patch is based on 2008.08.08 release. I have already posted a version in devel mailing list, now I submit to tracker for simpler tracking.
Thanks to Adar's review. More comments are welcomed.

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

>Comment By: Adar Dembo (adembo)
Date: 2008-09-13 15:11

Message:
Thanks, Yiwhen. The screenshots look good; no problems there.

I'm still having some issues applying your patches, though:
- For each patch, make sure your e-mail address is listed. Some of them
show root@localhost.localdomain.
- For each patch, provide an explicit commit message title and details.
Some of the patches show "put your commit message title" as the message
title and "put your commit message details" in the details.
- Don't worry about "testing done" and "reviewers" if there aren't any for
a particular patch.
- Most importantly, all the file paths in your patches lack an
"open-vm-tools/" prefix. This means that when I try to apply them using
git-am, git can't find the files to patch. Could you either rebuild your
patches with the prefix in place in the file paths, or explain to me how I
should use git-am (or git-apply) so that I can connect the files in your
patches to my files?

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

Comment By: ven (ven9)
Date: 2008-09-11 05:39

Message:
Thank you for the comments. They sound reasonable. I have made adjust.
I have made ( and tested ) patch chain along with required screenshots.
They are packed in the attachment. The button layout may not be elegant for
various window size, though.
File Added: commit.tar.gz

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-11 01:22

Message:
I've looked at your second patch, and here is another round of comments:
- I'm trying to use git's workflow to incorporate your patches. To that
end, could you use git-format-patch to format your patches? That way I
should be able to use git-am to apply them easily (so make sure you can use
git-am locally to apply them).
- I'd like to see a screenshot of the new tab you've added to the gtk
toolbox. I'd also appreciate a screenshot of the error presented by
Toolsmain_MsgBox.
- In GuestApp_ControlRecord, refer to statelogger_backdoor_def.h without
the path. That way, we could move statelogger_backdoor_def.h to a new
location in the future without updating this comment.
- Don't bother calling out the isolation flag in RECORD_VMX_ERR. We cover
them exhaustively in the product manuals, and mentioning it by name in this
code will make it harder to change the name of the flag in the future.
- I have some cosmetic suggestions regarding the wording in
RECORD_VMX_ERR. Here's an alternative wording:
"Error, the Record/Replay control operation failed. This could be for one
of the following reasons:\n" \
"1. You are running an old version of a VMware product." \
"2. Your product has disabled these controls. To enable them, consult the
product documentation.\n\n" \
"3. You tried to start a recording while already recording.\n\n" \
"4. You tried to stop a recording while already not recording.\n\n"


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

Comment By: ven (ven9)
Date: 2008-09-09 23:04

Message:
Correct my typos and incorporate the new macros. Also add some
informational error message.
The new patch is applied after the first one.
File Added: record-control2.patch

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-03 00:02

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

Looks good, just two more requests out of me:
- "proccess" --> "process" in GuestApp_ControlRecord.
- I'm attaching statelogger_backdoor_def.h which contains a very
rudimentary record of this backdoor protocol. Could you incorporate it into
your patch, using its macros where appropriate?
File Added: statelogger_backdoor_def.h

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

Comment By: ven (ven9)
Date: 2008-09-01 02:58

Message:
Logged In: YES 
user_id=2082796
Originator: YES

Any comments?

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

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

[open-vm-tools-devel] [ open-vm-tools-Tracker-1960947 ] procps-devel and proc/sysinfo.h

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

Tracker item #1960947, was opened at 2008-05-09 04:09
Message generated for change (Comment added) made by adembo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=1960947&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: misc
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Johnny Hughes (hughesjr)
Assigned to: Nobody/Anonymous (nobody)
Summary: procps-devel and proc/sysinfo.h

Initial Comment:
The procps package in several linux distributions does not contain the header file (proc/sysinfo.h) by default.

(CentOS, RHEL, Fedora, Mandriva, Ubuntu, and opensuse do not contain that header file by default ... it seems it is only in Debian by default)

The upstream "make install" also does not install that header.


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

>Comment By: Adar Dembo (adembo)
Date: 2008-09-12 18:50

Message:
Alright, I committed a patch to git that should fix this problem. Could you
guys check it out and let me know if it doesn't work for you? Otherwise,
it'll be in the next code refresh and at that point I'll close this bug.

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-05 10:59

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

Sorry for not providing an update earlier. Our intern Daniel was going to
take a look at this but got swamped with other tasks.

I think I'll go with the solution used in those dkms packages, though
there'll be a few ripples in configure.ac, so it may take me some time to
sort it out.

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

Comment By: Denis Leroy (poolshark)
Date: 2008-09-05 03:11

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

Any updates on this ?

It's important to understand that right now, the configure script will
fail by default on EVERY linux distribution but Debian. The use of procps
should be turned on explicitly by an option rather than the other way
round.


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

Comment By: Denis Leroy (poolshark)
Date: 2008-05-12 23:15

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

Ugh, I'd get flamed to a crisp if I did this in Fedora :-) It would also
be hard to convince the Fedora/RHEL maintainer to export the header files,
since this is a deviation from upstream.

I would recommend the solution I used for my dkms packages at

http://www.poolshark.org/dkms-open-vm-tools/dkms-open-vm-tools-0-1.2008.04.14.fc8.src.rpm

This one has a patch that add the few prototypes needed to compile the
code.


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

Comment By: Johnny Hughes (hughesjr)
Date: 2008-05-12 14:09

Message:
Logged In: YES 
user_id=1166174
Originator: YES

Well ... I cheated :D

I just extracted the CentOS-5 procps source and tared up the /proc header
files and added them as a Source to my open-vm-tools SRPM, then I untared
them into open-vm-tools BUILD root (in lib/include/proc modified the path
in the configure file to look in the new place.

That is not a very good option, but it was the fastest/easiest.  I will
have to track the source manually and modify the headers if required.

The other option is to create a proper -devel file for procps .. which I
would do if CentOS was not a rebuild of RHEL sources.  Since it is, I am
kind of stuck with their procps RPM as defined.

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

Comment By: ECL (sopwith)
Date: 2008-05-12 12:17

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

Hey Johnny, do you have any suggestions for viable solutions? I think we
were looking at trying to remove the dependency on libprocps, but what
other options are there from your perspective?

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

Comment By: Dmitriy (bryndin)
Date: 2008-05-09 11:55

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

In Mandriva case, /usr/include/procps is created instead of
/usr/include/proc.
creating a soft link solves the problem.

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

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

Re: [open-vm-tools-devel] Possible license problem

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

> Great! Thank you. Do you have any slightest any idea when it will be
> refreshed/released?

The schedule is monthly since the refreshes involve some work. Since the last one took place in early September, it's likely the next one will be in early October.

Could you just cherry pick the patch into whatever open-vm-tools snapshot you're working with?

[open-vm-tools-devel] Вячеслав А Гребенщиков вне офиса

[<V.G...@ur...>]

<html><body>
<p>Меня не будет на работе с  12.09.2008 по 29.09.2008.<br>
<br>
За меня Валерий В Лазаренко. Телефон 010-4380</body></html>

Re: [open-vm-tools-devel] Possible license problem

[Pavol R. <pr...@su...>]

Adar Dembo wrote:

> This patch is now in git and will also be in the next open-vm-tools code refresh.

Great! Thank you. Do you have any slightest any idea when it will be 
refreshed/released?

-- 
Best Regards / S pozdravom,

Pavol RUSNAK                                       SUSE LINUX, s.r.o
Package Maintainer                                Lihovarska 1060/12
PGP 0xA6917144                                     19000 Praha 9, CR
prusnak[at]suse.cz                                http://www.suse.cz

Re: [open-vm-tools-devel] Possible license problem

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

> I think it might be safe to remove the notice, but I'll double check with
> our legal department and ping the xorg guys. Thanks for reporting this
> issue.

OK, I just committed a patch that modifies the DEC license in region.c according to what I found in http://bugs.freedesktop.org/show_bug.cgi?id=283. Basically, we forked miregion.c a long time ago (from RealVNC, and they forked it from XFree86), back when the license was less permissive. Since then, the xorg guys got permission from Compaq to alter the license.

What I did was refork miregion.c from xorg and apply all open-vm-tools region.c patches to it other than the existing license. This patch is now in git and will also be in the next open-vm-tools code refresh.

[open-vm-tools-devel] [ open-vm-tools-Tracker-2064471 ] FEATURE:control vm recording by toolbox

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

Tracker item #2064471, was opened at 2008-08-21 18:41
Message generated for change (Comment added) made by ven9
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2064471&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: ven (ven9)
Assigned to: Nobody/Anonymous (nobody)
Summary: FEATURE:control vm recording by toolbox

Initial Comment:
A patch that affects both vmware-toolbox and vmware-toolbox-cmd, adding start/stop recording functionalities for them. It adds a new GuestApp routine, through vmware backdoor, to do it, a new panel for toolbox and a new command for toolbox-cmd as UI.
This patch is based on 2008.08.08 release. I have already posted a version in devel mailing list, now I submit to tracker for simpler tracking.
Thanks to Adar's review. More comments are welcomed.

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

>Comment By: ven (ven9)
Date: 2008-09-11 20:39

Message:
Thank you for the comments. They sound reasonable. I have made adjust.
I have made ( and tested ) patch chain along with required screenshots.
They are packed in the attachment. The button layout may not be elegant for
various window size, though.
File Added: commit.tar.gz

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-11 16:22

Message:
I've looked at your second patch, and here is another round of comments:
- I'm trying to use git's workflow to incorporate your patches. To that
end, could you use git-format-patch to format your patches? That way I
should be able to use git-am to apply them easily (so make sure you can use
git-am locally to apply them).
- I'd like to see a screenshot of the new tab you've added to the gtk
toolbox. I'd also appreciate a screenshot of the error presented by
Toolsmain_MsgBox.
- In GuestApp_ControlRecord, refer to statelogger_backdoor_def.h without
the path. That way, we could move statelogger_backdoor_def.h to a new
location in the future without updating this comment.
- Don't bother calling out the isolation flag in RECORD_VMX_ERR. We cover
them exhaustively in the product manuals, and mentioning it by name in this
code will make it harder to change the name of the flag in the future.
- I have some cosmetic suggestions regarding the wording in
RECORD_VMX_ERR. Here's an alternative wording:
"Error, the Record/Replay control operation failed. This could be for one
of the following reasons:\n" \
"1. You are running an old version of a VMware product." \
"2. Your product has disabled these controls. To enable them, consult the
product documentation.\n\n" \
"3. You tried to start a recording while already recording.\n\n" \
"4. You tried to stop a recording while already not recording.\n\n"


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

Comment By: ven (ven9)
Date: 2008-09-10 14:04

Message:
Correct my typos and incorporate the new macros. Also add some
informational error message.
The new patch is applied after the first one.
File Added: record-control2.patch

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-03 15:02

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

Looks good, just two more requests out of me:
- "proccess" --> "process" in GuestApp_ControlRecord.
- I'm attaching statelogger_backdoor_def.h which contains a very
rudimentary record of this backdoor protocol. Could you incorporate it into
your patch, using its macros where appropriate?
File Added: statelogger_backdoor_def.h

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

Comment By: ven (ven9)
Date: 2008-09-01 17:58

Message:
Logged In: YES 
user_id=2082796
Originator: YES

Any comments?

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

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

[open-vm-tools-devel] [ open-vm-tools-Tracker-2064471 ] FEATURE:control vm recording by toolbox

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

Tracker item #2064471, was opened at 2008-08-21 03:41
Message generated for change (Comment added) made by adembo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2064471&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: ven (ven9)
Assigned to: Nobody/Anonymous (nobody)
Summary: FEATURE:control vm recording by toolbox

Initial Comment:
A patch that affects both vmware-toolbox and vmware-toolbox-cmd, adding start/stop recording functionalities for them. It adds a new GuestApp routine, through vmware backdoor, to do it, a new panel for toolbox and a new command for toolbox-cmd as UI.
This patch is based on 2008.08.08 release. I have already posted a version in devel mailing list, now I submit to tracker for simpler tracking.
Thanks to Adar's review. More comments are welcomed.

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

>Comment By: Adar Dembo (adembo)
Date: 2008-09-11 01:22

Message:
I've looked at your second patch, and here is another round of comments:
- I'm trying to use git's workflow to incorporate your patches. To that
end, could you use git-format-patch to format your patches? That way I
should be able to use git-am to apply them easily (so make sure you can use
git-am locally to apply them).
- I'd like to see a screenshot of the new tab you've added to the gtk
toolbox. I'd also appreciate a screenshot of the error presented by
Toolsmain_MsgBox.
- In GuestApp_ControlRecord, refer to statelogger_backdoor_def.h without
the path. That way, we could move statelogger_backdoor_def.h to a new
location in the future without updating this comment.
- Don't bother calling out the isolation flag in RECORD_VMX_ERR. We cover
them exhaustively in the product manuals, and mentioning it by name in this
code will make it harder to change the name of the flag in the future.
- I have some cosmetic suggestions regarding the wording in
RECORD_VMX_ERR. Here's an alternative wording:
"Error, the Record/Replay control operation failed. This could be for one
of the following reasons:\n" \
"1. You are running an old version of a VMware product." \
"2. Your product has disabled these controls. To enable them, consult the
product documentation.\n\n" \
"3. You tried to start a recording while already recording.\n\n" \
"4. You tried to stop a recording while already not recording.\n\n"


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

Comment By: ven (ven9)
Date: 2008-09-09 23:04

Message:
Correct my typos and incorporate the new macros. Also add some
informational error message.
The new patch is applied after the first one.
File Added: record-control2.patch

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-03 00:02

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

Looks good, just two more requests out of me:
- "proccess" --> "process" in GuestApp_ControlRecord.
- I'm attaching statelogger_backdoor_def.h which contains a very
rudimentary record of this backdoor protocol. Could you incorporate it into
your patch, using its macros where appropriate?
File Added: statelogger_backdoor_def.h

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

Comment By: ven (ven9)
Date: 2008-09-01 02:58

Message:
Logged In: YES 
user_id=2082796
Originator: YES

Any comments?

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

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

[open-vm-tools-devel] [ open-vm-tools-Tracker-2064471 ] FEATURE:control vm recording by toolbox

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

Tracker item #2064471, was opened at 2008-08-21 18:41
Message generated for change (Comment added) made by ven9
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2064471&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: ven (ven9)
Assigned to: Nobody/Anonymous (nobody)
Summary: FEATURE:control vm recording by toolbox

Initial Comment:
A patch that affects both vmware-toolbox and vmware-toolbox-cmd, adding start/stop recording functionalities for them. It adds a new GuestApp routine, through vmware backdoor, to do it, a new panel for toolbox and a new command for toolbox-cmd as UI.
This patch is based on 2008.08.08 release. I have already posted a version in devel mailing list, now I submit to tracker for simpler tracking.
Thanks to Adar's review. More comments are welcomed.

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

>Comment By: ven (ven9)
Date: 2008-09-10 14:04

Message:
Correct my typos and incorporate the new macros. Also add some
informational error message.
The new patch is applied after the first one.
File Added: record-control2.patch

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

Comment By: Adar Dembo (adembo)
Date: 2008-09-03 15:02

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

Looks good, just two more requests out of me:
- "proccess" --> "process" in GuestApp_ControlRecord.
- I'm attaching statelogger_backdoor_def.h which contains a very
rudimentary record of this backdoor protocol. Could you incorporate it into
your patch, using its macros where appropriate?
File Added: statelogger_backdoor_def.h

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

Comment By: ven (ven9)
Date: 2008-09-01 17:58

Message:
Logged In: YES 
user_id=2082796
Originator: YES

Any comments?

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

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

Re: [open-vm-tools-devel] Possible license problem

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

> File lib/region/region.c contains following comment:

[snip]

> If I'm right, we (distribution) are not able to redistribute this file
> and thus not able to include open-vm-tools into distro. Is there
> anything that can be done? I would be very unhappy to remove
> open-vm-tools from SUSE. Thanks for the explanation!

Just before that comment is another one:

/* The panoramix components contained the following notice */

I can't find any references to "panoramix" (or xinerama, since I think panoramix is the old name for it) in the rest of the file. The actual miregion.c file in the xorg repository still has the notice too, even though I don't see any references to panoramix in that file when I dig through the git history.

I think it might be safe to remove the notice, but I'll double check with our legal department and ping the xorg guys. Thanks for reporting this issue.

[open-vm-tools-devel] Possible license problem

[Pavol R. <pr...@su...>]

Hi all!

File lib/region/region.c contains following comment:

/****************************************************************
*                                                               *
*    Copyright (c) $OWNER, $YEARS
*                                                               *
*   All Rights Reserved.  Unpublished rights  reserved  under   *
*   the copyright laws of the United States.                    *
*                                                               *
*   The software contained on this media  is  proprietary  to   *
*   and  embodies  the  confidential  technology  of  Digital   *
*   Equipment Corporation.  Possession, use,  duplication  or   *
*   dissemination of the software and media is authorized only  *
*   pursuant to a valid written license from Digital Equipment  *
*   Corporation.                                                *
*                                                               *
*   RESTRICTED RIGHTS LEGEND   Use, duplication, or disclosure  *
*   by the U.S. Government is subject to restrictions  as  set  *
*   forth in Subparagraph (c)(1)(ii)  of  DFARS  252.227-7013,  *
*   or  in  FAR 52.227-19, as applicable.                       *
*                                                               *
*****************************************************************/

If I'm right, we (distribution) are not able to redistribute this file 
and thus not able to include open-vm-tools into distro. Is there 
anything that can be done? I would be very unhappy to remove 
open-vm-tools from SUSE. Thanks for the explanation!

-- 
Best Regards / S pozdravom,

Pavol RUSNAK                                       SUSE LINUX, s.r.o
Package Maintainer                                Lihovarska 1060/12
PGP 0xA6917144                                     19000 Praha 9, CR
prusnak[at]suse.cz                                http://www.suse.cz

Re: [open-vm-tools-devel] Status of VMCI in open-vm-tools w.r.t workstation version

[Jorgen S. H. <jh...@vm...>]

Hi Cam,

The most recent version of the VMCI driver is intended for the upcoming hardware version 7, e.g., Workstation 6.5, and won't work on any current version of Workstation (6.0.x) or Fusion (1.x). There has been a fundamental change in the VMCI virtual hardware moving to hardware version 7, and the new driver is not backwards compatible.

The change involves the complete removal of the shared memory API from VMCI, and the removal of the VMCI user level SDK. The new user level API is VMCI sockets - see http://www.vmware.com/products/beta/ws/VMCIsockets.pdf

Thanks,
Jorgen


> -----Original Message-----
> From: ope...@li... [mailto:open-
> vm-...@li...] On Behalf Of Cam
> Macdonell
> Sent: Friday, September 05, 2008 11:25 AM
> To: DIscussions relating to development of the open-vm-tools project
> Subject: [open-vm-tools-devel] Status of VMCI in open-vm-tools w.r.t
> workstation version
>
>
> Hi,
>
> So I tried to use the latest copy of open-vm-tools to use with VMCI on
> workstation 6.0.2.  However, despite it building properly the module
> will not load.  It gives an error that I referred to yesterday that I
> have tracked down to this change in vmci_drv.c:
>
> vmci_drv.c from: VMwareTools-6.0.2-59824.tar.gz had this:
>
>     capabilities = inl(ioaddr + VMCI_CAPS_ADDR);
>
>     if ((capabilities & VMCI_CAPS_HYPERCALL) == 0) {
>        printk(KERN_ERR "VMCI device does not support hypercalls.\n");
>        goto release;
>     }
>     if ((capabilities & VMCI_CAPS_GUESTCALL) == 0) {
>        printk(KERN_ERR "VMCI device does not support guestcalls.\n");
>        goto release;
>     }
>
> where as vmci_drv.c in the current git has this to:
>
>     capabilities = inl(ioaddr + VMCI_CAPS_ADDR);
>
>     if ((capabilities & VMCI_CAPS_DATAGRAM) == 0) {
>        printk(KERN_ERR "VMCI device does not support datagrams.\n");
>        goto release;
>     }
>
> Under what version of workstation is this datagram capability present
> in
> the VMCI device?
>
> Thanks,
> Cam
>
> -----------------------------------------------------------------------
> --
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> open-vm-tools-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel