[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1172650184.11949.96.camel@localhost.localdomain>
Date: Wed, 28 Feb 2007 09:09:44 +0100
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Arnd Bergmann <arnd@...db.de>,
Arjan van de Ven <arjan@...radead.org>,
Ingo Molnar <mingo@...e.hu>, linux-arch@...r.kernel.org,
linux-kernel@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Andi Kleen <ak@...e.de>, Alan Cox <alan@...rguk.ukuu.org.uk>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC] killing the NR_IRQS arrays.
> 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.
I wouldn't bother too much about going into bus specific bits like
irq_request(dev, ...). Well, actually, I _do_ think it's a good thing to
pass the struct device to irq_request but that's a different issue
completely.
I think bus types should provide bus specific helpers to obtain the
struct irq *'s for a given device on that bus, but the API for
requesting/freeing them shall remain generic.
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists