All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Juri Lelli <juri.lelli@arm.com>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
	peterz@infradead.org, vincent.guittot@linaro.org,
	robh+dt@kernel.org, mark.rutland@arm.com, linux@arm.linux.org.uk,
	sudeep.holla@arm.com, lorenzo.pieralisi@arm.com,
	catalin.marinas@arm.com, will.deacon@arm.com,
	morten.rasmussen@arm.com, dietmar.eggemann@arm.com,
	broonie@kernel.org
Subject: Re: [PATCH v4 8/8] arm,arm64,drivers: add a prefix to drivers arch_topology interfaces
Date: Thu, 25 May 2017 15:18:02 +0200	[thread overview]
Message-ID: <20170525131802.GE16244@kroah.com> (raw)
In-Reply-To: <20170420144316.15632-9-juri.lelli@arm.com>

On Thu, Apr 20, 2017 at 03:43:16PM +0100, Juri Lelli wrote:
> Now that some functions that deal with arch topology information live
> under drivers, there is a clash of naming that might create confusion.
> 
> Tidy things up by creating a drivers namespace for interfaces used by
> arch code; achieve this by prepending a 'atd_' (arch topology driver)
> prefix to driver interfaces.

No one knows, nor will they ever remember, what "atd_" means :(

Naming is hard, I know, here's my suggestion:

> diff --git a/include/linux/arch_topology.h b/include/linux/arch_topology.h
> index 4edae9fe8cdd..e25458d7ee9a 100644
> --- a/include/linux/arch_topology.h
> +++ b/include/linux/arch_topology.h
> @@ -4,14 +4,14 @@
>  #ifndef _LINUX_ARCH_TOPOLOGY_H_
>  #define _LINUX_ARCH_TOPOLOGY_H_
>  
> -void normalize_cpu_capacity(void);
> +void atd_normalize_cpu_capacity(void);

arch_cpu_normalize_capacity();
or
cpu_normalize_capacity();

Why do you care if this is "arch" or not, of course it's arch-specific
in a way, right?

>  
>  struct device_node;
> -int parse_cpu_capacity(struct device_node *cpu_node, int cpu);
> +int atd_parse_cpu_capacity(struct device_node *cpu_node, int cpu);

cpu_parse_capacity();

>  struct sched_domain;
> -unsigned long arch_scale_cpu_capacity(struct sched_domain *sd, int cpu);
> +unsigned long atd_scale_cpu_capacity(struct sched_domain *sd, int cpu);

cpu_scale_capacity();

> -void set_capacity_scale(unsigned int cpu, unsigned long capacity);
> +void atd_set_capacity_scale(unsigned int cpu, unsigned long capacity);

wait, where did the cpu go?  This doesn't make much sense, these are all
"capacity" issues, right?  If so, then these should be:
	capacity_normalize_cpu()
	capacity_parse_cpu()
	capacity_scale_cpu()
	capacity_set_scale()

But this is all really topology stuff, right?  Why use "capacity" at
all:
	topology_normalize_cpu()
	topology_parse_cpu()
	topology_scale_cpu()
	topology_set_scale()
?

It's always best to put the "subsystem" name first, we have a bad
history of getting this wrong in the past by putting the verb first, not
the noun.

thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: gregkh@linuxfoundation.org (Greg KH)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 8/8] arm,arm64,drivers: add a prefix to drivers arch_topology interfaces
Date: Thu, 25 May 2017 15:18:02 +0200	[thread overview]
Message-ID: <20170525131802.GE16244@kroah.com> (raw)
In-Reply-To: <20170420144316.15632-9-juri.lelli@arm.com>

On Thu, Apr 20, 2017 at 03:43:16PM +0100, Juri Lelli wrote:
> Now that some functions that deal with arch topology information live
> under drivers, there is a clash of naming that might create confusion.
> 
> Tidy things up by creating a drivers namespace for interfaces used by
> arch code; achieve this by prepending a 'atd_' (arch topology driver)
> prefix to driver interfaces.

No one knows, nor will they ever remember, what "atd_" means :(

Naming is hard, I know, here's my suggestion:

> diff --git a/include/linux/arch_topology.h b/include/linux/arch_topology.h
> index 4edae9fe8cdd..e25458d7ee9a 100644
> --- a/include/linux/arch_topology.h
> +++ b/include/linux/arch_topology.h
> @@ -4,14 +4,14 @@
>  #ifndef _LINUX_ARCH_TOPOLOGY_H_
>  #define _LINUX_ARCH_TOPOLOGY_H_
>  
> -void normalize_cpu_capacity(void);
> +void atd_normalize_cpu_capacity(void);

arch_cpu_normalize_capacity();
or
cpu_normalize_capacity();

Why do you care if this is "arch" or not, of course it's arch-specific
in a way, right?

>  
>  struct device_node;
> -int parse_cpu_capacity(struct device_node *cpu_node, int cpu);
> +int atd_parse_cpu_capacity(struct device_node *cpu_node, int cpu);

cpu_parse_capacity();

>  struct sched_domain;
> -unsigned long arch_scale_cpu_capacity(struct sched_domain *sd, int cpu);
> +unsigned long atd_scale_cpu_capacity(struct sched_domain *sd, int cpu);

cpu_scale_capacity();

> -void set_capacity_scale(unsigned int cpu, unsigned long capacity);
> +void atd_set_capacity_scale(unsigned int cpu, unsigned long capacity);

wait, where did the cpu go?  This doesn't make much sense, these are all
"capacity" issues, right?  If so, then these should be:
	capacity_normalize_cpu()
	capacity_parse_cpu()
	capacity_scale_cpu()
	capacity_set_scale()

But this is all really topology stuff, right?  Why use "capacity" at
all:
	topology_normalize_cpu()
	topology_parse_cpu()
	topology_scale_cpu()
	topology_set_scale()
?

It's always best to put the "subsystem" name first, we have a bad
history of getting this wrong in the past by putting the verb first, not
the noun.

thanks,

greg k-h

  reply	other threads:[~2017-05-25 13:18 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-20 14:43 [PATCH v4 0/8] Fix issues and factorize arm/arm64 capacity information code Juri Lelli
2017-04-20 14:43 ` Juri Lelli
2017-04-20 14:43 ` Juri Lelli
2017-04-20 14:43 ` [PATCH v4 1/8] Documentation: arm: fix wrong reference number in DT definition Juri Lelli
2017-04-20 14:43   ` Juri Lelli
2017-04-20 14:43 ` [PATCH v4 2/8] Documentation/ABI: add information about cpu_capacity Juri Lelli
2017-04-20 14:43   ` Juri Lelli
2017-04-20 14:43   ` Juri Lelli
2017-04-20 14:43 ` [PATCH v4 4/8] arm: remove wrong CONFIG_PROC_SYSCTL ifdef Juri Lelli
2017-04-20 14:43   ` Juri Lelli
2017-04-20 14:43   ` Juri Lelli
2017-04-20 14:43 ` [PATCH v4 5/8] arm, arm64: factorize common cpu capacity default code Juri Lelli
2017-04-20 14:43   ` Juri Lelli
2017-05-25 13:12   ` Greg KH
2017-05-25 13:12     ` Greg KH
2017-04-20 14:43 ` [PATCH v4 7/8] arm,arm64,drivers: move externs in a new header file Juri Lelli
2017-04-20 14:43   ` Juri Lelli
2017-05-25 13:13   ` Greg KH
2017-05-25 13:13     ` Greg KH
2017-04-20 14:43 ` [PATCH v4 8/8] arm,arm64,drivers: add a prefix to drivers arch_topology interfaces Juri Lelli
2017-04-20 14:43   ` [PATCH v4 8/8] arm, arm64, drivers: " Juri Lelli
2017-05-25 13:18   ` Greg KH [this message]
2017-05-25 13:18     ` [PATCH v4 8/8] arm,arm64,drivers: " Greg KH
     [not found]     ` <20170525131802.GE16244-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2017-05-26 10:10       ` Juri Lelli
2017-05-26 10:10         ` Juri Lelli
2017-05-26 10:10         ` Juri Lelli
2017-05-26 18:36         ` Greg KH
2017-05-26 18:36           ` Greg KH
2017-05-26 18:36           ` Greg KH
2017-05-29  9:20           ` Dietmar Eggemann
2017-05-29  9:20             ` Dietmar Eggemann
2017-05-29  9:58             ` Greg KH
2017-05-29  9:58               ` Greg KH
2017-05-29 10:46               ` Dietmar Eggemann
2017-05-29 10:46                 ` Dietmar Eggemann
2017-05-30 14:59                 ` Juri Lelli
2017-05-30 14:59                   ` Juri Lelli
     [not found] ` <20170420144316.15632-1-juri.lelli-5wv7dgnIgG8@public.gmane.org>
2017-04-20 14:43   ` [PATCH v4 3/8] arm: fix return value of parse_cpu_capacity Juri Lelli
2017-04-20 14:43     ` Juri Lelli
2017-04-20 14:43     ` Juri Lelli
2017-04-20 14:50     ` Vincent Guittot
2017-04-20 14:50       ` Vincent Guittot
2017-04-20 14:43   ` [PATCH v4 6/8] arm,arm64,drivers: reduce scope of cap_parsing_failed Juri Lelli
2017-04-20 14:43     ` Juri Lelli
2017-04-20 14:43     ` Juri Lelli
2017-05-25 13:13     ` Greg KH
2017-05-25 13:13       ` Greg KH
2017-05-11  8:48   ` [PATCH v4 0/8] Fix issues and factorize arm/arm64 capacity information code Juri Lelli
2017-05-11  8:48     ` Juri Lelli
2017-05-11  8:48     ` Juri Lelli
2017-05-11  8:59     ` Greg KH
2017-05-11  8:59       ` Greg KH
     [not found]       ` <20170511085952.GA6934-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2017-05-11 10:27         ` Juri Lelli
2017-05-11 10:27           ` Juri Lelli
2017-05-11 10:27           ` Juri Lelli
2017-05-24 14:45           ` Juri Lelli
2017-05-24 14:45             ` Juri Lelli
2017-05-25 13:18             ` Greg KH
2017-05-25 13:18               ` Greg KH
2017-05-25 13:18               ` Greg KH
     [not found]               ` <20170525131831.GF16244-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2017-05-25 13:30                 ` Juri Lelli
2017-05-25 13:30                   ` Juri Lelli
2017-05-25 13:30                   ` Juri Lelli

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=20170525131802.GE16244@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=morten.rasmussen@arm.com \
    --cc=peterz@infradead.org \
    --cc=robh+dt@kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=vincent.guittot@linaro.org \
    --cc=will.deacon@arm.com \
    /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.