linux-kernel - Re: [RFC PATCH v1] irqchip: Add IRQCHIP_MODULE

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] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 11 Apr 2020 10:14:47 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Saravana Kannan <saravanak@...gle.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>,
        John Stultz <john.stultz@...aro.org>, kernel-team@...roid.com,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v1] irqchip: Add IRQCHIP_MODULE_BEGIN/END helper macros

Hi Saravana,

On Sat, 11 Apr 2020 05:59:18 +0100,
Saravana Kannan <saravanak@...gle.com> wrote:
> 
> Add helper macros IRQCHIP_MODULE_BEGIN and IRQCHIP_MODULE_END that add
> the boilerplate code to be able to compile an irqchip driver as a
> module.
> 
> The driver developer just needs to do add IRQCHIP_MODULE_BEGIN and
> IRQCHIP_MODULE_END(driver_name) around the IRQCHIP_DECLARE macros, like
> so:
> 
> IRQCHIP_MODULE_BEGIN
> IRQCHIP_DECLARE(foo, "acme,foo", acme_foo_init)
> IRQCHIP_DECLARE(bar, "acme,bar", acme_bar_init)
> IRQCHIP_MODULE_END(acme_irq)
> 
> Cc: John Stultz <john.stultz@...aro.org>
> Signed-off-by: Saravana Kannan <saravanak@...gle.com>
> ---
> I don't expect this patch to be perfect or the final version. But I'd
> like to introduce macros like this that don't need the driver developer
> to copy/paste or repeat the same thing (compat string, function name,
> etc) in multiple places for the driver to work as a module. If the exact
> style of my macros aren't appealing, I'm open to other suggestions.
> 
> There are some checkpatch warning about the > 80 columns that my patch
> doesn't add. There are also checkpatch warnings about the trailing ; in
> a macro, but I need those for IRQCHIP_DECLARE to work when the driver is
> builtin.

I think you are looking at the problem from the wrong end, and adding
syntactic sugar should be the least of your worries. The reason for
not allowing irqchip drivers to be modular is that there is no
refcounting in place to prevent drivers from being removed whilst the
IRQ stack still has irq_desc, irq_data and various other objects
indirectly referencing the driver.

I'm all for addressing these issues, though it begs the question of
*why* you want to do this. We have been perfectly happy with built-in
irqchips so far (they are pretty small, and there aren't millions of
them), so what changed?

Thanks,

	M.

-- 
Jazz is not dead, it just smells funny.