From: Thomas Gleixner <tglx@linutronix.de>
To: Bart Van Assche <bvanassche@acm.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Russell King <linux@armlinux.org.uk>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 01/21] genirq: Introduce number_of_interrupts() and set_number_of_interrupts()
Date: Wed, 02 Oct 2024 17:49:42 +0200 [thread overview]
Message-ID: <87ikuawlm1.ffs@tglx> (raw)
In-Reply-To: <bd377620-7781-4b93-98c1-93f778b74724@acm.org>
On Tue, Oct 01 2024 at 13:12, Bart Van Assche wrote:
> On 10/1/24 5:33 AM, Thomas Gleixner wrote:
>> On Mon, Sep 30 2024 at 11:15, Bart Van Assche wrote:
>>> This patch prepares for changing 'nr_irqs' from an exported global
>>> variable
>>
>> git grep 'This patch' Documentation/process/
>
> Is this the documentation that you are referring to? Anyway, I will
> change the patch description into the imperative mood. <quote>Describe
> your changes in imperative mood, e.g. "make xyzzy do frotz"
> instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
> to do frotz", as if you are giving orders to the codebase to change
> its behaviour.</quote>
Yes.
>>> into a variable with file scope.
>>
>> Also what's the rationale for this?
>
> Suppose that a patch would be submitted for review that removes a
> declaration of a local variable with the name 'nr_irqs' and that does
> not remove all assignments to that local variable. Such a patch converts
> an assignment to a local variable into an assignment into a global
> variable. If the 'nr_irqs' assignment is more than three lines away from
> other changes, the assignment won't be included in the diff context
> lines and hence won't be visible without inspecting the modified file.
> This is why I mentioned in the cover letter that this change makes
> patches easier to review. With this patch series applied, such
> accidental conversions from assignments to a local variable into an
> assignment to a global variable are converted into a compilation
> error.
Can you please add that to the change log?
>>> extern int nr_irqs;
>>> +int number_of_interrupts(void) __pure;
>>> +int set_number_of_interrupts(int nr);
>>
>> Please use a proper name space prefix for the functions
>> irq_.....(). These random names are horrible.
>
> How about irq_count() and irq_set_count()?
Sure.
>>> +int number_of_interrupts(void)
>>> +{
>>> + return nr_irqs;
>>
>> Why is this int? The number of interrupts is strictly positive, no?
>
> Yes, the number of interrupts is strictly positive. The return type
> comes from the type of 'nr_irqs' and been chosen to minimize the risk of
> the changes in this patch series. Anyway, I will audit the code that
> reads and sets the global 'nr_irqs' variable to see whether its type can
> be changed safely into 'unsigned int'.
Thank you!
tglx
next prev parent reply other threads:[~2024-10-02 15:49 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-30 18:15 [PATCH 00/21] Reduce the scope of 'nr_irqs' Bart Van Assche
2024-09-30 18:15 ` [PATCH 01/21] genirq: Introduce number_of_interrupts() and set_number_of_interrupts() Bart Van Assche
2024-10-01 12:33 ` Thomas Gleixner
2024-10-01 20:12 ` Bart Van Assche
2024-10-02 15:49 ` Thomas Gleixner [this message]
2024-10-03 21:01 ` Bart Van Assche
2024-10-06 19:58 ` Thomas Gleixner
2024-09-30 18:15 ` [PATCH 02/21] ARM: Switch to number_of_interrupts() / set_number_of_interrupts() Bart Van Assche
2024-09-30 18:15 ` [PATCH 03/21] LoongArch: Switch to set_number_of_interrupts() Bart Van Assche
2024-09-30 18:15 ` [PATCH 04/21] powerpc/cell: Switch to number_of_interrupts() Bart Van Assche
2024-09-30 18:15 ` [PATCH 05/21] s390/irq: " Bart Van Assche
2024-09-30 18:15 ` [PATCH 06/21] x86/acpi: Switch to number_of_interrupts() / set_number_of_interrupts() Bart Van Assche
2024-09-30 18:15 ` [PATCH 07/21] hpet: Switch to number_of_interrupts() Bart Van Assche
2024-10-06 17:13 ` David Laight
2024-10-07 0:45 ` Bart Van Assche
2024-10-07 12:11 ` Thomas Gleixner
2024-10-07 13:00 ` David Laight
2024-10-07 15:27 ` Thomas Gleixner
2024-09-30 18:15 ` [PATCH 08/21] net: 3com: 3c59x: " Bart Van Assche
2024-09-30 18:15 ` [PATCH 09/21] net: hamradio: baycom_ser_fdx: " Bart Van Assche
2024-09-30 18:15 ` [PATCH 10/21] scsi: aha152x: " Bart Van Assche
2024-09-30 18:15 ` [PATCH 11/21] serial: core: " Bart Van Assche
2024-09-30 18:15 ` [PATCH 12/21] serial: 8250: " Bart Van Assche
2024-09-30 18:15 ` [PATCH 13/21] serial: amba-pl010: " Bart Van Assche
2024-09-30 18:15 ` [PATCH 14/21] serial: amba-pl011: " Bart Van Assche
2024-09-30 18:15 ` [PATCH 15/21] serial: cpm_uart: " Bart Van Assche
2024-09-30 18:15 ` [PATCH 16/21] serial: ucc_uart: " Bart Van Assche
2024-09-30 18:15 ` [PATCH 17/21] sh: intc: " Bart Van Assche
2024-09-30 18:15 ` [PATCH 18/21] xen/events: " Bart Van Assche
2024-09-30 18:15 ` [PATCH 19/21] fs/procfs: " Bart Van Assche
2024-09-30 18:15 ` [PATCH 20/21] genirq: " Bart Van Assche
2024-10-07 16:26 ` Bart Van Assche
2024-09-30 18:16 ` [PATCH 21/21] genirq: Unexport nr_irqs Bart Van Assche
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=87ikuawlm1.ffs@tglx \
--to=tglx@linutronix.de \
--cc=bvanassche@acm.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
/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.