docs: fix usage of 'onto'

http://www.uhv.edu/ac/newsletters/writing/grammartip2009.07.01.htm
(and several other sites) give hints that 'onto' is best used if
you can also add 'up' just before it and still make sense. In many
cases in the code base, we really want the two-word form, or even
a simplification to just 'on' or 'to'.

* docs/hacking.html.in: Use correct 'on to'.
* python/libvirt-override.c: Likewise.
* src/lxc/lxc_controller.c: Likewise.
* src/util/virpci.c: Likewise.
* daemon/THREADS.txt: Use simpler 'on'.
* docs/formatdomain.html.in: Better usage.
* docs/internals/rpc.html.in: Likewise.
* src/conf/domain_event.c: Likewise.
* src/rpc/virnetclient.c: Likewise.
* tests/qemumonitortestutils.c: Likewise.
* HACKING: Regenerate.
Signed-off-by: NEric Blake <eblake@redhat.com>

HACKING

@@ -330,7 +330,7 @@ Omitting braces with a single-line body is fine:
   while (expr) // one-line body -> omitting curly braces is ok
       single_line_stmt();
 
-However, the moment your loop/if/else body extends onto a second line, for
+However, the moment your loop/if/else body extends on to a second line, for
 whatever reason (even if it's just an added comment), then you should add
 braces. Otherwise, it would be too easy to insert a statement just before that
 comment (without adding braces), thinking it is already a multi-statement loop:

daemon/THREADS.txt

@@ -40,7 +40,7 @@ The server lock is used in conjunction with a condition variable
 to pass jobs from the event loop thread to the workers. The main
 event loop thread handles I/O from the client socket, and once a
 complete RPC message has been read off the wire (and optionally
-decrypted), it will be placed onto the 'dx' job queue for the
+decrypted), it will be placed on the 'dx' job queue for the
 associated client object. The job condition will be signalled and
 a worker will wakup and process it.
 

docs/formatdomain.html.in

@@ -741,7 +741,7 @@
 
     <p>
       Resource partitions are currently supported by the QEMU and
-      LXC drivers, which map partition paths onto cgroups directories,
+      LXC drivers, which map partition paths to cgroups directories,
       in all mounted controllers. <span class="since">Since 1.0.5</span>
     </p>
 
@@ -2701,7 +2701,7 @@
     </p>
 
     <p>
-      Provides a bridge from the VM directly onto the LAN. This assumes
+      Provides a bridge from the VM directly to the LAN. This assumes
       there is a bridge device on the host which has one or more of the hosts
       physical NICs enslaved. The guest VM will have an associated tun device
       created with a name of vnetN, which can also be overridden with the
@@ -2908,7 +2908,7 @@
     <dl>
       <dt><code>profileid</code></dt>
       <dd>The profile ID contains the name of the port profile that is to
-        be applied onto this interface.  This name is resolved by the port
+        be applied to this interface.  This name is resolved by the port
         profile database into the network parameters from the port profile,
         and those network parameters will be applied to this interface.
       </dd>

docs/hacking.html.in

@@ -394,7 +394,7 @@
 </pre>
 
     <p>
-      However, the moment your loop/if/else body extends onto a second
+      However, the moment your loop/if/else body extends on to a second
       line, for whatever reason (even if it's just an added comment), then
       you should add braces.  Otherwise, it would be too easy to insert a
       statement just before that comment (without adding braces), thinking

docs/internals/rpc.html.in

@@ -418,7 +418,7 @@
       After a complete packet has been read, the header must be decoded
       and all 6 fields fully validated, before attempting to dispatch
       the payload. Once dispatched, the payload can be decoded and passed
-      onto the appropriate API for execution. The RPC code must not take
+      on to the appropriate API for execution. The RPC code must not take
       any action based on the payload, since it has no way to validate
       the semantics of the payload data. It must delegate this to the
       execution API (e.g. corresponding libvirt public API).
@@ -785,7 +785,7 @@
       return value and output parameters, or error object and encode
       them into a reply packet. Again it does not attempt to do any
       semantic validation of output data, aside from variable length
-      field limit checks. The worker thread puts the reply packet onto
+      field limit checks. The worker thread puts the reply packet on
       the transmission queue for the client. The worker is now finished
       and goes back to wait for another incoming method call.
     </p>
@@ -811,10 +811,10 @@
       for the worker threads, it is sidetracked into a per-stream
       processing queue. When the stream becomes writable, queued
       incoming stream packets will be processed, passing their data
-      payload onto the stream. Conversely when the stream becomes
+      payload on the stream. Conversely when the stream becomes
       readable, chunks of data will be read from it, encoded into
       new outgoing packets, and placed on the client's transmit
-      queue
+      queue.
     </p>
 
     <h4><a name="apiserverdispatchex1">Example with overlapping methods</a></h4>

python/libvirt-override.c

@@ -4,7 +4,7 @@
  *           entry points where an automatically generated stub is
  *           unpractical
  *
- * Copyright (C) 2005, 2007-2012 Red Hat, Inc.
+ * Copyright (C) 2005, 2007-2013 Red Hat, Inc.
  *
  * Daniel Veillard <veillard@redhat.com>
  */
@@ -5084,7 +5084,7 @@ libvirt_virEventRegisterImpl(ATTRIBUTE_UNUSED PyObject * self,
     updateTimeoutName = py_str(updateTimeoutObj);
     removeTimeoutName = py_str(removeTimeoutObj);
 
-    /* Inc refs since we're holding onto these objects until
+    /* Inc refs since we're holding on to these objects until
      * the next call (if any) to this function.
      */
     Py_INCREF(addHandleObj);

src/conf/domain_event.c

 /*
  * domain_event.c: domain event queue processing helpers
  *
- * Copyright (C) 2010-2012 Red Hat, Inc.
+ * Copyright (C) 2010-2013 Red Hat, Inc.
  * Copyright (C) 2008 VirtualIron
  *
  * This library is free software; you can redistribute it and/or
@@ -1179,7 +1179,7 @@ virDomainEventPtr virDomainEventBalloonChangeNewFromObj(virDomainObjPtr obj,
  * @evtQueue: the dom event queue
  * @event: the event to add
  *
- * Internal function to push onto the back of a virDomainEventQueue
+ * Internal function to push to the back of a virDomainEventQueue
  *
  * Returns: 0 on success, -1 on failure
  */

src/lxc/lxc_controller.c

@@ -1699,7 +1699,7 @@ int main(int argc, char *argv[])
             _exit(0);
         }
 
-        /* Don't hold onto any cwd we inherit from libvirtd either */
+        /* Don't hold on to any cwd we inherit from libvirtd either */
         if (chdir("/") < 0) {
             virReportSystemError(errno, "%s",
                                  _("Unable to change to root dir"));

src/rpc/virnetclient.c

 /*
  * virnetclient.c: generic network RPC client
  *
- * Copyright (C) 2006-2012 Red Hat, Inc.
+ * Copyright (C) 2006-2013 Red Hat, Inc.
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Lesser General Public
@@ -1771,7 +1771,7 @@ static int virNetClientIO(virNetClientPtr client,
             goto cleanup;
         }
 
-        /* Grr, someone passed the buck onto us ... */
+        /* Grr, someone passed the buck to us ... */
     } else {
         client->haveTheBuck = true;
     }

src/util/virpci.c

@@ -1208,8 +1208,8 @@ virPCIDeviceReattach(virPCIDevicePtr dev,
  * condition where the hypervisor is still cleaning up the device while
  * libvirt is trying to re-attach it to the host device driver.  To avoid
  * this situation, we look through /proc/iomem, and if the hypervisor is
- * still holding onto the bar (denoted by the string in the matcher variable),
- * then we can wait around a bit for that to clear up.
+ * still holding on to the bar (denoted by the string in the matcher
+ * variable), then we can wait around a bit for that to clear up.
  *
  * A typical /proc/iomem looks like this (snipped for brevity):
  * 00010000-0008efff : System RAM
@@ -1230,7 +1230,7 @@ virPCIDeviceReattach(virPCIDevicePtr dev,
  *   f0000000-f0003fff : kvm_assigned_device
  *
  * Returns 0 if we are clear to continue, and 1 if the hypervisor is still
- * holding onto the resource.
+ * holding on to the resource.
  */
 int
 virPCIDeviceWaitForCleanup(virPCIDevicePtr dev, const char *matcher)

tests/qemumonitortestutils.c

@@ -77,7 +77,7 @@ struct _qemuMonitorTest {
 static void qemuMonitorTestItemFree(qemuMonitorTestItemPtr item);
 
 /*
- * Appends data for a reply onto the outgoing buffer
+ * Appends data for a reply to the outgoing buffer
  */
 static int qemuMonitorTestAddReponse(qemuMonitorTestPtr test,
                                      const char *response)