From: Andrey Panin <pazke@donpac.ru>
To: Anton Blanchard <anton@samba.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH][RFC] irq handling code consolidation (common part)
Date: Fri, 27 Jun 2003 09:00:20 +0400 [thread overview]
Message-ID: <20030627050020.GX9679@pazke> (raw)
In-Reply-To: <20030626175554.GA22089@krispykreme>
[-- Attachment #1: Type: text/plain, Size: 1751 bytes --]
On 178, 06 27, 2003 at 03:55:54AM +1000, Anton Blanchard wrote:
>
> > the irq handling consolidation patch returns from the dead !
> > Now with runaway irq detection code included !
> >
> > This patch (against 2.5.73) contains common part of it.
>
> Great! Well it wasnt dead, I was also keeping it up to date and sending
> it on to akpm :)
>
> I have two suggestions that will help in my crusade to kill NR_IRQS.
>
> 1. define irq_desc, irq_valid, for_each_irq in include/linux/irq.h if
> HAVE_ARCH_IRQ_DESC isnt defined (instead of in each architecture).
> Basically I want to start using these macros in a few places and dont
> want to break every architecture that hasnt converted to the new scheme.
Why in include/linux/irq.h ? These macros are definetely arch specific.
Do you talk about generic array based implementation wrapped in
#ifdef ARCH_HAVE_FOO ?
> On the other hand if we decide to move the irq descriptor definition
> into each arch as hch suggested, this wont be necessary as all archs
> will break anyway :)
Why it will break ? Every arch defines irq descriptors itself now.
May be I'm missing some point here ?
> 2. define irq_atoi that converts an irq into a printable string. We have
> a bunch of #ifdef CONFIG_SPARC stuff we can then get rid of, and other
> archs can start using it if wanted (eg on ppc64 I can subtract our
> software offset so the irqs printed match the hardware)
I thinked about this already, but i wanted to finish cleanup work first.
BTW sparc implementation of irq_itoa() uses static buffer for the formatted
string, is it really irq/preempt safe ?
--
Andrey Panin | Linux and UNIX system administrator
pazke@donpac.ru | PGP key: wwwkeys.pgp.net
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2003-06-27 4:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-26 11:02 [PATCH][RFC] irq handling code consolidation (common part) Andrey Panin
2003-06-26 11:13 ` Christoph Hellwig
2003-06-27 4:33 ` Andrey Panin
2003-06-26 17:55 ` Anton Blanchard
2003-06-27 5:00 ` Andrey Panin [this message]
2003-06-27 6:04 ` Miles Bader
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=20030627050020.GX9679@pazke \
--to=pazke@donpac.ru \
--cc=anton@samba.org \
--cc=linux-kernel@vger.kernel.org \
/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.