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]
Message-ID: <86sghas7so.wl-maz@kernel.org>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ