[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.1003211541120.3147@localhost.localdomain>
Date: Sun, 21 Mar 2010 15:43:47 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
cc: Yinghai Lu <yinghai@...nel.org>, Ingo Molnar <mingo@...e.hu>,
"H. Peter Anvin" <hpa@...or.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Julia Lawall <julia@...u.dk>,
Suresh Siddha <suresh.b.siddha@...el.com>,
LKML <linux-kernel@...r.kernel.org>, linux-arch@...r.kernel.org
Subject: Re: [PATCH] irq: Start the transition of irq_chip methods taking a
desc
Eric,
On Sun, 21 Mar 2010, Eric W. Biederman wrote:
>
> With SPARSE_IRQ irq_to_desc becomes an unnecessary lookup operation on
> the fast path of dispatching irqs to their handlers. We can avoid
> this cost by passing an irq_desc pointer instead of using an integer
> irq token to the irq_chip methods.
>
> A single patch to convert all of the architectures is an unreviewable
> 2000+ line patch. A gradual transition scenario with two sets of
> irq_chip methods in irq_chip is an unmanageable mess in kernel/irq.
>
> So instead I define some macros so the generic irq code in kernel/irq/
> can compile either way based on a boolean Kconfig variable
> CONFIG_CHIP_PARAM_DESC. This allows us to convert one architecture at
> a time, reducing the follow on patches to manageable proportions. It
> is a little bit ugly but it is much better than the alternatives, and
> as soon as we finish the transition we can kill the macros.
>
> I introduce the macros CHIP_ARG, CHIP_VAR, and CHIP_PARAM where
> appropriate. I change a few declarations of irq as int to unsigned
> int. I normalize the variables names in the functions that call
> chip methods to ensure that I have the variables irq and desc present
> allowing CHIP_ARG to work properly. Most importantly none of the irq
> logic changes with this patch.
I like that approach very much. Is the output binary equivivalent?
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists