lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <b4eabf2f-5c88-4d36-89e3-d27cda0eef36@acm.org>
Date: Thu, 3 Oct 2024 14:01:13 -0700
From: Bart Van Assche <bvanassche@....org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Russell King <linux@...linux.org.uk>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/21] genirq: Introduce number_of_interrupts() and
 set_number_of_interrupts()

On 10/2/24 8:49 AM, Thomas Gleixner wrote:
> 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:
>>>> 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?

I will do that.

>>>>    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.

I just noticed that a macro with the name irq_count() already exists.
How about the names irq_get_nr_irqs() and irq_set_nr_irqs() instead?

Thanks,

Bart.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ