From: Arnd Bergmann <arnd@arndb.de>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Arjan van de Ven <arjan@infradead.org>,
Ingo Molnar <mingo@elte.hu>,
linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Andi Kleen <ak@suse.de>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [RFC] killing the NR_IRQS arrays.
Date: Wed, 28 Feb 2007 01:41:50 +0100 [thread overview]
Message-ID: <200702280141.51420.arnd@arndb.de> (raw)
In-Reply-To: <m1abyzl4yw.fsf@ebiederm.dsl.xmission.com>
On Tuesday 27 February 2007, Eric W. Biederman wrote:
> * Add a variation of the API in interrupt.h that uses
> "struct irq *irq" instead of "unsigned int irq"
>
> Probably replacing request_irq with irq_request or something
> trivial like that.
>
> This will need to touch all of different irq implementation back
> ends, but only very lightly.
>
> * Convert the generic irq code to use struct irq * everywhere it
> current uses "unsigned int irq".
>
> * Start on the conversions of drivers and subsystems picking on
> the easy ones first :)
Introducing the irq_request() etc. functions that take a struct irq*
instead of an int sounds good, but I'd hope we can avoid using those
in device drivers and do a separate abstraction for each bus_type
that deals with interrupts. I'm not sure if that's possible for
each bus_type, but the ones I have worked with in the past should
allow that:
pci: each device/function has a unique irq, drivers need not know
about it afaics.
isa/pnp: numbers from 1 to 15 are the right abstraction here, that
how isa has worked for ages.
s390: got rid of irq numbers already
ofw: an open firmware device can have a number of interrupts, but
like PCI, the driver only needs to know things like 'first
irq of this device', not how it's connected
ps3: irqs are requested from the firmware for each device, this
can happen under the covers.
mmc, usb, phy, ieee1394: these already have a higl-level abstraction
for interrupt events
platform: dunno, probably these really should use the struct irq
directly
eisa, mca, pcmcia, zorro, ...: no idea, but possibly similar to PCI.
Note that we can even start converting device drivers first, before
moving away from irq numbers. A typical PCI driver should get
somewhat simpler by the conversion, and when they are all converted,
we can replace pci_dev->irq with a struct irq* under the covers.
Arnd <><
next prev parent reply other threads:[~2007-02-28 0:43 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-16 12:10 [RFC] killing the NR_IRQS arrays Eric W. Biederman
2007-02-16 12:10 ` Eric W. Biederman
2007-02-16 12:16 ` Andi Kleen
2007-02-16 15:35 ` Eric W. Biederman
2007-02-16 12:41 ` Ingo Molnar
2007-02-16 15:23 ` Eric W. Biederman
2007-02-16 15:49 ` Eric W. Biederman
2007-02-16 22:33 ` Benjamin Herrenschmidt
2007-02-18 21:24 ` Arjan van de Ven
2007-02-19 0:25 ` Benjamin Herrenschmidt
2007-02-27 20:29 ` Eric W. Biederman
2007-02-28 0:41 ` Arnd Bergmann [this message]
2007-02-28 7:20 ` Eric W. Biederman
2007-02-28 8:09 ` Benjamin Herrenschmidt
2007-02-28 13:28 ` Eric W. Biederman
2007-02-28 12:24 ` Arnd Bergmann
2007-02-28 13:02 ` Segher Boessenkool
2007-02-28 13:53 ` Eric W. Biederman
2007-03-01 10:47 ` Benjamin Herrenschmidt
2007-02-16 18:07 ` Jeremy Fitzhardinge
2007-02-16 19:01 ` Eric W. Biederman
2007-02-16 19:06 ` Jeremy Fitzhardinge
2007-02-16 19:45 ` Arnd Bergmann
2007-02-16 19:52 ` Russell King
2007-02-16 20:43 ` Arnd Bergmann
2007-02-16 20:59 ` Russell King
2007-02-16 22:37 ` Benjamin Herrenschmidt
2007-02-17 1:37 ` Arnd Bergmann
2007-02-17 4:00 ` Benjamin Herrenschmidt
2007-02-17 9:06 ` Eric W. Biederman
2007-02-17 21:15 ` Benjamin Herrenschmidt
2007-02-18 6:30 ` Eric W. Biederman
2007-02-18 20:01 ` Benjamin Herrenschmidt
2007-02-17 9:34 ` Eric W. Biederman
2007-02-17 21:20 ` Benjamin Herrenschmidt
2007-02-18 3:58 ` Eric W. Biederman
2007-02-16 22:29 ` Benjamin Herrenschmidt
2007-02-17 8:51 ` Eric W. Biederman
2007-02-17 21:04 ` Benjamin Herrenschmidt
2007-02-18 4:58 ` Eric W. Biederman
2007-02-18 19:58 ` Benjamin Herrenschmidt
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=200702280141.51420.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arjan@infradead.org \
--cc=benh@kernel.crashing.org \
--cc=ebiederm@xmission.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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.