public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Arnd Bergmann <arnd@arndb.de>
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 00:20:34 -0700	[thread overview]
Message-ID: <m14pp6kat9.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <200702280141.51420.arnd@arndb.de> (Arnd Bergmann's message of "Wed, 28 Feb 2007 01:41:50 +0100")

Arnd Bergmann <arnd@arndb.de> writes:

>
> 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.
Then there is msi and with msi-x you can have up to 4K irqs.

> isa/pnp: numbers from 1 to 15 are the right abstraction here, that
>      how isa has worked for ages.

There is some truth there yes.  But for ISA the numbers are really
0 to 15.  

> s390: got rid of irq numbers already

Yes.  I should really look at that more and see if I could bring
s390 into the generic irq code with my planned changes.

> 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
Yes.

> 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.

Largely for pci we already have dev->irq and the device just calls
request_irq to get things going.  The challenge is that the token
in dev->irq get's looked at.

> 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.

Reasonable if it is easy and straight forward.
Something like pci_request_irq(dev,....) and the helper looks at
dev->irq under the covers and calls request_irq or whatever makes
sense.  Is this what you are thinking.  Examples would help me here.


What I really object to is not the irq numbers.  As an arbitrary number
does not impose limits.  What I object to is drivers that can't handle the
full range of numbers, and the limits imposed upon those numbers when
you require them to be indexes into an array.

For talking to user space I expect we will have numbers for a long time
to come yet.

Eric


  reply	other threads:[~2007-02-28  7:22 UTC|newest]

Thread overview: 40+ 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: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
2007-02-28  7:20           ` Eric W. Biederman [this message]
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=m14pp6kat9.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arjan@infradead.org \
    --cc=arnd@arndb.de \
    --cc=benh@kernel.crashing.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox