The Linux Kernel Mailing List
 help / color / mirror / Atom feed
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 --]

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox