lkml.org 
[lkml]   [2003]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH][RFC] irq handling code consolidation (common part)
From
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
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-03-22 13:36    [W:0.050 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site