Re: [Xen-devel] [PATCH v2 05/10] xen: credit2: tidy up functions names by removing leading '__'.

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Thu, Feb 9, 2017 at 1:58 PM, Dario Faggioli
<dario.faggioli@xxxxxxxxxx> wrote:
> There is no reason for having pretty much all of the
> functions whose names begin with double underscores
> ('__') to actually look like that.
>
> In fact, that is misleading and makes the code hard
> to read and understand. So, remove the '__'-s.
>
> The only two that we keep are __runq_assign() and
> __runq_deassign() (althought they're converted to
> single underscore). In fact, in those cases, it is
> indeed useful to have those sort of a "raw" variants.
>
> In case of __runq_insert(), which is only called
> once, by runq_insert(), merge the two functions.
>
> No functional change intended.
>
> Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx>

Acked-by: George Dunlap <george.dunlap@xxxxxxxxxx>

With one comment...

> ---
> Cc: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
> Cc: Anshul Makkar <anshul.makkar@xxxxxxxxxx>
> ---
>  xen/common/sched_credit2.c |  114 
> +++++++++++++++++++-------------------------
>  1 file changed, 49 insertions(+), 65 deletions(-)
>
> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
> index 786dcca..4b4f4f8 100644
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -221,7 +221,7 @@ integer_param("sched_credit2_migrate_resist", 
> opt_migrate_resist);
>   * shift all time samples to the right.
>   *
>   * The details of the formulas used for load tracking are explained close to
> - * __update_runq_load(). Let's just say here that, with full nanosecond time
> + * update_runq_load(). Let's just say here that, with full nanosecond time
>   * granularity, a 30 bits wide 'decaying window' is ~1 second long.
>   *
>   * We want to consider the following equations:
> @@ -233,7 +233,7 @@ integer_param("sched_credit2_migrate_resist", 
> opt_migrate_resist);
>   * Q-format fixed point arithmetic and load is the instantaneous load of a
>   * runqueue, which basically is the number of runnable vcpus there are on the
>   * runqueue (for the meaning of the other terms, look at the doc comment to
> - *  __update_runq_load()).
> + *  update_runq_load()).
>   *
>   *  So, again, with full nanosecond granularity, and 1 second window, we 
> have:
>   *
> @@ -594,14 +594,12 @@ static s_time_t c2t(struct csched2_runqueue_data *rqd, 
> s_time_t credit, struct c
>   * Runqueue related code
>   */
>
> -static /*inline*/ int
> -__vcpu_on_runq(struct csched2_vcpu *svc)
> +static inline int vcpu_on_runq(struct csched2_vcpu *svc)
>  {
>      return !list_empty(&svc->runq_elem);
>  }
>
> -static /*inline*/ struct csched2_vcpu *
> -__runq_elem(struct list_head *elem)
> +static struct csched2_vcpu * runq_elem(struct list_head *elem)
>  {
>      return list_entry(elem, struct csched2_vcpu, runq_elem);
>  }

Would it make sense to make this inline as well?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel