Linux-PM Archive on lore.kernel.org
 help / color / Atom feed
From: Mikko Perttunen <mikko.perttunen-/1wQRMveznE@public.gmane.org>
To: Juha-Matti Tilli <juha-matti.tilli-X3B1VOXEql0@public.gmane.org>
Cc: Thierry Reding
	<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Mikko Perttunen <cyndis-/1wQRMveznE@public.gmane.org>,
	edubezval-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org,
	linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Mikko Perttunen
	<mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH v6 4/4] thermal: Add Tegra SOCTHERM thermal management driver
Date: Mon, 29 Sep 2014 16:42:53 +0300
Message-ID: <542961DD.5000003@kapsi.fi> (raw)
In-Reply-To: <20140927120649.GA70809-Xv4IVSKz7SWQi9Q/X01l6/UpdFzICT1y@public.gmane.org>

On 09/27/2014 03:06 PM, Juha-Matti Tilli wrote:
> On Fri, Sep 26, 2014 at 11:28:31PM +0300, Mikko Perttunen wrote:
>>> I think a more idiomatic way to write this would be:
>>>
>>> static int
>>> calculate_tsensor_calibration(const struct tegra_tsensor *sensor,
>>>                                struct tsensor_shared_calibration shared,
>>>                                u32 *calib)
> [snip]
>>>
>>> While at it, perhaps make shared a const * instead of passing it in by
>>> value?
>>
>> That is possible, but I'm not sure what the difference would be. Is
>> there a style rule forbidding by-value compound types? (Also if I change
>> the style, it would go over 80 characters by even more.)
>
> I guess the idea is that it's more space- and time-efficient to pass
> compound types as pointers instead of by value. Kernel stack is quite
> limited in size, so allocating structs from stack in this way quickly
> eats up the stack. Furthermore, there's less machine language
> instructions in the function call if passed as a pointer, because when
> passed as a value, each member of the struct needs to be pushed to the
> stack separately (unless the member size is smaller than word length of
> the machine architecture, in which case the compiler may optimize a
> bit). So it's faster, too, to pass by pointer. In the case of kernel
> coding, of these problems the limited stack size is far more serious.

I can accept that saving kernel stack space is a good reason to use 
pointers. And since as you below mentioned, there is no line length 
issue, I'll change this.

>
> In this case, however, the current struct is only 16 bytes vs 4/8 bytes
> for a pointer, so it shouldn't matter that much. But IMO as a general
> rule it's a far better style to pass compound types as pointers. I would
> definitely pass by pointer here instead of passing by value even given
> that the advantages in this particular case are limited. You should
> consider the possibility that in a future driver version struct
> tsensor_shared_calibration may become larger, and thus the code will be
> closer to stack overflow if the one who increases the size of struct
> tsensor_shared_calibration doesn't notice that it is passed by value.
>
> There are always ways to structure the code so that it looks fine and
> the additional "const *" will not cause the line length to become >80
> chars. In my opinion, line length considerations should never play a
> role on deciding whether to pass by value or pass by pointer. I don't
> understand why you think this particular function would have line length
> problems. In my opinion, the following is 78 chars max:
>
> static int
> calculate_tsensor_calibration(const struct tegra_tsensor *sensor,
>                                const struct tsensor_shared_calibration *shared,
>                                u32 *calib)

Good point. I usually never use this style, so I didn't think of doing 
it like that. But it is clearly the best solution.

>
> Of course, if you want to have "static int" on the same line as the
> function name, then you'll have problems but even those can be avoided
> so that the code still looks fine:
>
> static int calculate_tsensor_calibration(const struct tegra_tsensor *sensor,
>                                           const struct
>                                               tsensor_shared_calibration *shared,
>                                           u32 *calib)
>
> Anyway, the root cause of line length problems here is overlong
> identifiers. For example, "calculate_tsensor_calibration" is in my
> opinion too long for a function name. You could easily abbreviate it to
> "calc_tsensor_calib" without losing any information. Similarly, "struct
> tsensor_shared_calibration" could be easily abbreviated to "struct
> tsensor_shared_calib". Then you could have easily:
>
> static int calc_tsensor_calib(const struct tegra_tsensor *sensor,
>                                const struct tsensor_shared_calib *shared,
>                                u32 *calib)
>
> without being even close to the 80-character line length limitation.

Yes, might be.

> --
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Mikko

  parent reply index

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-26  9:43 [PATCH v6 0/4] Tegra124 soctherm driver Mikko Perttunen
     [not found] ` <1411724593-4037-1-git-send-email-cyndis-/1wQRMveznE@public.gmane.org>
2014-09-26  9:43   ` [PATCH v6 1/4] of: Add bindings for nvidia,tegra124-soctherm Mikko Perttunen
2014-09-26  9:43 ` [PATCH v6 2/4] ARM: tegra: Add soctherm and thermal zones to Tegra124 device tree Mikko Perttunen
2014-09-26  9:43 ` [PATCH v6 3/4] ARM: tegra: Add thermal trip points for Jetson TK1 Mikko Perttunen
2014-09-26  9:43 ` [PATCH v6 4/4] thermal: Add Tegra SOCTHERM thermal management driver Mikko Perttunen
2014-09-26 11:45   ` Thierry Reding
2014-09-26 20:28     ` Mikko Perttunen
2014-09-27 12:06       ` Juha-Matti Tilli
     [not found]         ` <20140927120649.GA70809-Xv4IVSKz7SWQi9Q/X01l6/UpdFzICT1y@public.gmane.org>
2014-09-29 13:42           ` Mikko Perttunen [this message]
2014-09-29  8:14       ` Peter De Schrijver
     [not found]       ` <5425CC6F.2020309-/1wQRMveznE@public.gmane.org>
2014-09-29  8:29         ` Thierry Reding
2014-09-29 13:37           ` Mikko Perttunen
2014-09-29 14:17   ` [PATCH v7 " Mikko Perttunen
2014-10-15 10:05     ` Mikko Perttunen
     [not found]       ` <543E46DF.8060705-/1wQRMveznE@public.gmane.org>
2014-11-07 15:54         ` Eduardo Valentin
2014-11-08  1:11           ` Mikko Perttunen
2014-09-26 10:19 ` [PATCH v6 0/4] Tegra124 soctherm driver Thierry Reding
2014-09-26 10:22   ` Mikko Perttunen
     [not found]     ` <54253E7C.9080704-/1wQRMveznE@public.gmane.org>
2014-09-26 11:48       ` Thierry Reding
2014-09-26 12:00         ` Mikko Perttunen
     [not found]           ` <5425554B.7060102-/1wQRMveznE@public.gmane.org>
2014-09-26 12:05             ` Thierry Reding
2014-09-26 12:09               ` Mikko Perttunen

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=542961DD.5000003@kapsi.fi \
    --to=mikko.perttunen-/1wqrmvezne@public.gmane.org \
    --cc=cyndis-/1wQRMveznE@public.gmane.org \
    --cc=edubezval-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=juha-matti.tilli-X3B1VOXEql0@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
    --cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.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

Linux-PM Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-pm/0 linux-pm/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-pm linux-pm/ https://lore.kernel.org/linux-pm \
		linux-pm@vger.kernel.org
	public-inbox-index linux-pm

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-pm


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git