All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Vrabel <david.vrabel@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: "Keir (Xen.org)" <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [RFC PATCH V3 01/22] Clean up trailing whitespaces
Date: Thu, 28 Feb 2013 11:30:56 +0000	[thread overview]
Message-ID: <512F3FF0.4060607@citrix.com> (raw)
In-Reply-To: <1361975655-22295-2-git-send-email-wei.liu2@citrix.com>

On 27/02/13 14:33, Wei Liu wrote:
> Affected files:
> * event_channel.c
> * sched.h
> * event.h
> * xen.h

Is this sort of white space patch useful?

David

> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  xen/common/event_channel.c |   16 ++++++++--------
>  xen/include/public/xen.h   |   22 +++++++++++-----------
>  xen/include/xen/event.h    |    4 ++--
>  xen/include/xen/sched.h    |    6 +++---
>  4 files changed, 24 insertions(+), 24 deletions(-)
> 
> diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
> index 2d7afc9..9231eb0 100644
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -1,15 +1,15 @@
>  /******************************************************************************
>   * event_channel.c
> - * 
> + *
>   * Event notifications from VIRQs, PIRQs, and other domains.
> - * 
> + *
>   * Copyright (c) 2003-2006, K A Fraser.
> - * 
> + *
>   * This program is distributed in the hope that it will be useful,
>   * but WITHOUT ANY WARRANTY; without even the implied warranty of
>   * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>   * GNU General Public License for more details.
> - * 
> + *
>   * You should have received a copy of the GNU General Public License
>   * along with this program; if not, write to the Free Software
>   * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
> @@ -238,7 +238,7 @@ static long evtchn_bind_interdomain(evtchn_bind_interdomain_t *bind)
>      lchn->u.interdomain.remote_dom  = rd;
>      lchn->u.interdomain.remote_port = (u16)rport;
>      lchn->state                     = ECS_INTERDOMAIN;
> -    
> +
>      rchn->u.interdomain.remote_dom  = ld;
>      rchn->u.interdomain.remote_port = (u16)lport;
>      rchn->state                     = ECS_INTERDOMAIN;
> @@ -255,7 +255,7 @@ static long evtchn_bind_interdomain(evtchn_bind_interdomain_t *bind)
>      spin_unlock(&ld->event_lock);
>      if ( ld != rd )
>          spin_unlock(&rd->event_lock);
> -    
> +
>      rcu_unlock_domain(rd);
>  
>      return rc;
> @@ -633,7 +633,7 @@ static void evtchn_set_pending(struct vcpu *v, int port)
>      {
>          vcpu_mark_events_pending(v);
>      }
> -    
> +
>      /* Check if some VCPU might be polling for this event. */
>      if ( likely(bitmap_empty(d->poll_mask, d->max_vcpus)) )
>          return;
> @@ -930,7 +930,7 @@ int evtchn_unmask(unsigned int port)
>  
>      /*
>       * These operations must happen in strict order. Based on
> -     * include/xen/event.h:evtchn_set_pending(). 
> +     * include/xen/event.h:evtchn_set_pending().
>       */
>      if ( test_and_clear_bit(port, &shared_info(d, evtchn_mask)) &&
>           test_bit          (port, &shared_info(d, evtchn_pending)) &&
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index 99c8212..87380e6 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -1,8 +1,8 @@
>  /******************************************************************************
>   * xen.h
> - * 
> + *
>   * Guest OS interface to Xen.
> - * 
> + *
>   * Permission is hereby granted, free of charge, to any person obtaining a copy
>   * of this software and associated documentation files (the "Software"), to
>   * deal in the Software without restriction, including without limitation the
> @@ -137,11 +137,11 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
>  #define __HYPERVISOR_dom0_op __HYPERVISOR_platform_op
>  #endif
>  
> -/* 
> +/*
>   * VIRTUAL INTERRUPTS
> - * 
> + *
>   * Virtual interrupts that a guest OS may receive from Xen.
> - * 
> + *
>   * In the side comments, 'V.' denotes a per-VCPU VIRQ while 'G.' denotes a
>   * global VIRQ. The former can be bound once per VCPU and cannot be re-bound.
>   * The latter can be allocated only once per guest: they must initially be
> @@ -190,7 +190,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
>   *                     (x) encodes the PFD as follows:
>   *                     x == 0 => PFD == DOMID_SELF
>   *                     x != 0 => PFD == x - 1
> - * 
> + *
>   * Sub-commands: ptr[1:0] specifies the appropriate MMU_* command.
>   * -------------
>   * ptr[1:0] == MMU_NORMAL_PT_UPDATE:
> @@ -236,13 +236,13 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
>   * To deallocate the pages, the operations are the reverse of the steps
>   * mentioned above. The argument is MMUEXT_UNPIN_TABLE for all levels and the
>   * pagetable MUST not be in use (meaning that the cr3 is not set to it).
> - * 
> + *
>   * ptr[1:0] == MMU_MACHPHYS_UPDATE:
>   * Updates an entry in the machine->pseudo-physical mapping table.
>   * ptr[:2]  -- Machine address within the frame whose mapping to modify.
>   *             The frame must belong to the FD, if one is specified.
>   * val      -- Value to write into the mapping entry.
> - * 
> + *
>   * ptr[1:0] == MMU_PT_UPDATE_PRESERVE_AD:
>   * As MMU_NORMAL_PT_UPDATE above, but A/D bits currently in the PTE are ORed
>   * with those in @val.
> @@ -588,7 +588,7 @@ typedef struct vcpu_time_info vcpu_time_info_t;
>  struct vcpu_info {
>      /*
>       * 'evtchn_upcall_pending' is written non-zero by Xen to indicate
> -     * a pending notification for a particular VCPU. It is then cleared 
> +     * a pending notification for a particular VCPU. It is then cleared
>       * by the guest OS /before/ checking for pending work, thus avoiding
>       * a set-and-check race. Note that the mask is only accessed by Xen
>       * on the CPU that is currently hosting the VCPU. This means that the
> @@ -646,7 +646,7 @@ struct shared_info {
>       *  3. Virtual interrupts ('events'). A domain can bind an event-channel
>       *     port to a virtual interrupt source, such as the virtual-timer
>       *     device or the emergency console.
> -     * 
> +     *
>       * Event channels are addressed by a "port index". Each channel is
>       * associated with two bits of information:
>       *  1. PENDING -- notifies the domain that there is a pending notification
> @@ -657,7 +657,7 @@ struct shared_info {
>       *     becomes pending while the channel is masked then the 'edge' is lost
>       *     (i.e., when the channel is unmasked, the guest must manually handle
>       *     pending notifications as no upcall will be scheduled by Xen).
> -     * 
> +     *
>       * To expedite scanning of pending notifications, any 0->1 pending
>       * transition on an unmasked channel causes a corresponding bit in a
>       * per-vcpu selector word to be set. Each bit in the selector covers a
> diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
> index 71c3e92..65ac81a 100644
> --- a/xen/include/xen/event.h
> +++ b/xen/include/xen/event.h
> @@ -1,8 +1,8 @@
>  /******************************************************************************
>   * event.h
> - * 
> + *
>   * A nice interface for passing asynchronous events to guest OSes.
> - * 
> + *
>   * Copyright (c) 2002-2006, K A Fraser
>   */
>  
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index ba0f2f8..f6846d4 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -92,7 +92,7 @@ void evtchn_destroy_final(struct domain *d); /* from complete_domain_destroy */
>  
>  struct waitqueue_vcpu;
>  
> -struct vcpu 
> +struct vcpu
>  {
>      int              vcpu_id;
>  
> @@ -453,7 +453,7 @@ struct domain *domain_create(
>  /*
>   * rcu_lock_domain_by_id() is more efficient than get_domain_by_id().
>   * This is the preferred function if the returned domain reference
> - * is short lived,  but it cannot be used if the domain reference needs 
> + * is short lived,  but it cannot be used if the domain reference needs
>   * to be kept beyond the current scope (e.g., across a softirq).
>   * The returned domain reference must be discarded using rcu_unlock_domain().
>   */
> @@ -574,7 +574,7 @@ void sync_local_execstate(void);
>   * sync_vcpu_execstate() will switch and commit @prev's state.
>   */
>  void context_switch(
> -    struct vcpu *prev, 
> +    struct vcpu *prev,
>      struct vcpu *next);
>  
>  /*

  reply	other threads:[~2013-02-28 11:30 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-27 14:33 [RFC PATCH V3] Implement 3-level event channel in Xen Wei Liu
2013-02-27 14:33 ` [RFC PATCH V3 01/22] Clean up trailing whitespaces Wei Liu
2013-02-28 11:30   ` David Vrabel [this message]
2013-02-28 11:36     ` Wei Liu
2013-02-28 11:38     ` Jan Beulich
2013-02-28 12:14       ` Ian Campbell
2013-02-28 12:29         ` Wei Liu
2013-02-28 13:08         ` Jan Beulich
2013-02-27 14:33 ` [RFC PATCH V3 02/22] Dynamically allocate d->evtchn Wei Liu
2013-02-27 16:35   ` Jan Beulich
2013-02-27 14:33 ` [RFC PATCH V3 03/22] Move event channel macros / struct definition to proper place Wei Liu
2013-02-27 14:33 ` [RFC PATCH V3 04/22] flask: include xen/event.h Wei Liu
2013-02-28 11:20   ` David Vrabel
2013-02-28 11:22     ` Wei Liu
2013-02-27 14:33 ` [RFC PATCH V3 05/22] Change MAX_EVTCHNS macro to max_evtchns inline function Wei Liu
2013-02-28 11:58   ` David Vrabel
2013-02-28 13:59     ` Wei Liu
2013-02-27 14:33 ` [RFC PATCH V3 06/22] Define extended event channel registration interface Wei Liu
2013-02-27 16:42   ` Jan Beulich
2013-02-28 11:25     ` Wei Liu
2013-02-28 11:32       ` Jan Beulich
2013-02-28 11:41         ` Wei Liu
2013-02-28 12:32   ` David Vrabel
2013-02-28 15:04     ` Wei Liu
2013-02-27 14:34 ` [RFC PATCH V3 07/22] Add evtchn_extended in struct domain Wei Liu
2013-02-28 11:55   ` David Vrabel
2013-02-27 14:34 ` [RFC PATCH V3 08/22] Calculate max event channels for EVTCHN_EXTENDED_L3 Wei Liu
2013-02-27 14:34 ` [RFC PATCH V3 09/22] Bump EVTCHNS_PER_BUCKET to 512 Wei Liu
2013-02-27 14:34 ` [RFC PATCH V3 10/22] Add evtchn_is_{pending, masked} and evtchn_clear_pending Wei Liu
2013-02-27 14:34 ` [RFC PATCH V3 11/22] Update Xen public header Wei Liu
2013-02-28 12:00   ` David Vrabel
2013-02-27 14:34 ` [RFC PATCH V3 12/22] Add supported extended event channel ABI bitmap Wei Liu
2013-02-27 16:47   ` Jan Beulich
2013-02-28 11:21     ` Wei Liu
2013-02-27 14:34 ` [RFC PATCH V3 13/22] Add evtchn_abi_str Wei Liu
2013-02-27 16:51   ` Jan Beulich
2013-02-28 11:28     ` Wei Liu
2013-02-28 11:33       ` Jan Beulich
2013-02-27 14:34 ` [RFC PATCH V3 14/22] Add control structures for 3-level event channel Wei Liu
2013-02-27 14:34 ` [RFC PATCH V3 15/22] Genneralized event channel operations Wei Liu
2013-02-27 14:34 ` [RFC PATCH V3 16/22] Introduce some macros for event channels Wei Liu
2013-02-27 16:53   ` Jan Beulich
2013-02-27 17:04     ` Ian Campbell
2013-02-28  7:54       ` Jan Beulich
2013-02-28  8:35         ` Ian Campbell
2013-02-28 11:17         ` Wei Liu
2013-02-27 14:34 ` [RFC PATCH V3 17/22] Infrastructure to manipulate 3-level event channel pages Wei Liu
2013-02-27 14:34 ` [RFC PATCH V3 18/22] Implement EVTCHNOP_register_extended Wei Liu
2013-02-28 12:33   ` David Vrabel
2013-02-27 14:34 ` [RFC PATCH V3 19/22] Enable exteneded event channel ABI query Wei Liu
2013-02-28 12:36   ` David Vrabel
2013-02-27 14:34 ` [RFC PATCH V3 20/22] Implement 3-level event channel routines Wei Liu
2013-02-27 14:34 ` [RFC PATCH V3 21/22] Only allow extended event channel on Dom0 and driver domains Wei Liu
2013-02-27 16:58   ` Jan Beulich
2013-02-28 11:19     ` Wei Liu
2013-02-28 12:43   ` David Vrabel
2013-02-28 19:29     ` Wei Liu
2013-02-27 14:34 ` [RFC PATCH V3 22/22] libxl: add evtchn_extended flag Wei Liu
2013-02-28 12:48   ` David Vrabel
2013-03-01 11:55   ` Ian Jackson
2013-02-27 16:28 ` [RFC PATCH V3] Implement 3-level event channel in Xen Keir Fraser
2013-02-27 17:01 ` Jan Beulich
2013-02-27 19:49   ` Keir Fraser
2013-02-27 23:19     ` Wei Liu
2013-02-28  5:58       ` Keir Fraser
2013-02-28  7:23     ` Jan Beulich
2013-03-01 12:00       ` Ian Jackson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=512F3FF0.4060607@citrix.com \
    --to=david.vrabel@citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=keir@xen.org \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.