* Stefan Weil (s...@weilnetz.de) wrote:
> * Remove trailing whitespace (fixes 9 errors from checkpatch.pl).
>   One comment line was longer than 80 characters, so wrap it
>   and fix a typo, too.
> * Replace tabs by blanks (fixes 1 error).
> 
> Signed-off-by: Stefan Weil <s...@weilnetz.de>

Needs merging with Michael's fixes, but otherwise:

Reviewed-by: Dr. David Alan Gilbert <dgilb...@redhat.com>

> ---
> 
> My editor automatically removes trailing whitespace, so before fixing code,
> I had to fix the coding style.
> 
>  migration/rdma.c |   22 +++++++++++-----------
>  1 file changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/migration/rdma.c b/migration/rdma.c
> index 6bee30c..67c5701 100644
> --- a/migration/rdma.c
> +++ b/migration/rdma.c
> @@ -703,7 +703,7 @@ static void qemu_rdma_dump_id(const char *who, struct 
> ibv_context *verbs)
>                  verbs->device->ibdev_path,
>                  port.link_layer,
>                  (port.link_layer == IBV_LINK_LAYER_INFINIBAND) ? 
> "Infiniband" :
> -                 ((port.link_layer == IBV_LINK_LAYER_ETHERNET) 
> +                 ((port.link_layer == IBV_LINK_LAYER_ETHERNET)
>                      ? "Ethernet" : "Unknown"));
>  }
>  
> @@ -738,7 +738,7 @@ static void qemu_rdma_dump_gid(const char *who, struct 
> rdma_cm_id *id)
>   * and validate what time of hardware it is.
>   *
>   * Unfortunately, this puts the user in a fix:
> - * 
> + *
>   *  If the source VM connects with an IPv4 address without knowing that the
>   *  destination has bound to '[::]' the migration will unconditionally fail
>   *  unless the management software is explicitly listening on the the IPv4
> @@ -746,13 +746,13 @@ static void qemu_rdma_dump_gid(const char *who, struct 
> rdma_cm_id *id)
>   *
>   *  If the source VM connects with an IPv6 address, then we're OK because we 
> can
>   *  throw an error on the source (and similarly on the destination).
> - * 
> + *
>   *  But in mixed environments, this will be broken for a while until it is 
> fixed
>   *  inside linux.
>   *
>   * We do provide a *tiny* bit of help in this function: We can list all of 
> the
>   * devices in the system and check to see if all the devices are RoCE or
> - * Infiniband. 
> + * Infiniband.
>   *
>   * If we detect that we have a *pure* RoCE environment, then we can safely
>   * thrown an error even if the management software has specified '[::]' as 
> the
> @@ -771,17 +771,17 @@ static int qemu_rdma_broken_ipv6_kernel(Error **errp, 
> struct ibv_context *verbs)
>      /* This bug only exists in linux, to our knowledge. */
>  #ifdef CONFIG_LINUX
>  
> -    /* 
> +    /*
>       * Verbs are only NULL if management has bound to '[::]'.
> -     * 
> +     *
>       * Let's iterate through all the devices and see if there any pure IB
>       * devices (non-ethernet).
> -     * 
> +     *
>       * If not, then we can safely proceed with the migration.
>       * Otherwise, there are no guarantees until the bug is fixed in linux.
>       */
>      if (!verbs) {
> -         int num_devices, x;
> +        int num_devices, x;
>          struct ibv_device ** dev_list = ibv_get_device_list(&num_devices);
>          bool roce_found = false;
>          bool ib_found = false;
> @@ -826,8 +826,8 @@ static int qemu_rdma_broken_ipv6_kernel(Error **errp, 
> struct ibv_context *verbs)
>  
>      /*
>       * If we have a verbs context, that means that some other than '[::]' was
> -     * used by the management software for binding. In which case we can 
> actually 
> -     * warn the user about a potential broken kernel;
> +     * used by the management software for binding. In which case we can
> +     * actually warn the user about a potentially broken kernel.
>       */
>  
>      /* IB ports start with 1, not 0 */
> @@ -2421,7 +2421,7 @@ static int qemu_rdma_dest_init(RDMAContext *rdma, Error 
> **errp)
>                          continue;
>                      }
>                  }
> -                    
> +
>                  goto listen;
>              }
>          }
> -- 
> 1.7.10.4
> 
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Reply via email to