Changeset 45697 in vbox for trunk/src/VBox/HostServices

Timestamp:

Apr 24, 2013 1:30:50 PM (12 years ago)

Author:

vboxsync

svn:sync-xref-src-repo-rev:

85242

Message:

GuestCtrl: Various bugfixes required for test driver to pass.

File:

• trunk/src/VBox/HostServices/GuestControl/service.cpp (modified) (5 diffs)

trunk/src/VBox/HostServices/GuestControl/service.cpp

@@ -332 +332 @@
                                 rc = VERR_INVALID_PARAMETER;
 
-                            if (paDstParms[i].u.pointer.size < mpParms[i].u.pointer.size)
+                            if (   RT_SUCCESS(rc)
+                                && paDstParms[i].u.pointer.size < mpParms[i].u.pointer.size)
                                 rc = VERR_BUFFER_OVERFLOW;
 
@@ -525 +526 @@
         mHostCmdRc    = VINF_SUCCESS;
         mHostCmdTries = 0;
+        mPeekCount    = 0;
 
         return nextItem;
@@ -630 +632 @@
         int rc = VINF_SUCCESS;
 
-        LogFlowFunc(("[Client %RU32] pConnection=%p, mHostCmdRc=%Rrc, mHostCmdTries=%RU32\n",
-                      mID, pConnection, mHostCmdRc, mHostCmdTries));
+        LogFlowFunc(("[Client %RU32] pConnection=%p, mHostCmdRc=%Rrc, mHostCmdTries=%RU32, mPeekCount=%RU32\n",
+                      mID, pConnection, mHostCmdRc, mHostCmdTries, mPeekCount));
 
         mHostCmdRc = SendReply(pConnection, pHostCmd);
@@ -644 +646 @@
             /*
              * If the client understood the message but supplied too little buffer space
-             * don't send this message again and drop it after 3 unsuccessful attempts.
-             * The host then should take care of next actions (maybe retry it with a smaller buffer).
+             * don't send this message again and drop it after 6 unsuccessful attempts.
+             *
+             * Note: Due to legacy reasons this the retry counter has to be even because on
+             *       every peek there will be the actual command retrieval from the client side.
+             *       To not get the actual command if the client actually only wants to peek for
+             *       the next command, there needs to be two rounds per try, e.g. 3 rounds = 6 tries.
+             *
+             ** @todo Fix the mess stated above. GUEST_MSG_WAIT should be become GUEST_MSG_PEEK, *only*
+             *        (and every time) returning the next upcoming host command (if any, blocking). Then
+             *        it's up to the client what to do next, either peeking again or getting the actual
+             *        host command via an own GUEST_ type message.
              */
             if (mHostCmdRc == VERR_TOO_MUCH_DATA)
             {
-                if (mHostCmdTries >= 3)
+                if (mHostCmdTries == 6)
                     fRemove = true;
             }
@@ -777 +788 @@
         else
         {
+            /* If this is the very first peek, make sure to *always* give back the peeking answer
+             * instead of the actual command, even if this command would fit into the current
+             * connection buffer. */
             if (!mPeekCount)
             {