[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080424163735.29ef21db@the-village.bc.nu>
Date: Thu, 24 Apr 2008 16:37:35 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Jeff Garzik <jeff@...zik.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Rene Herman <rene.herman@...access.nl>,
Adrian Bunk <bunk@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>, rmk@....linux.org.uk,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>
Subject: Re: [git patch] free_irq() fixes
> But then you'd have to have some way to "printk" the information, which is
> a very common requirement (and the printk still needs to be a number,
> because you want to match up 'dmesg' output with the '/proc/interrupts'
> file etc).
>
> That, in turn, would effectively force a whole new function, and then
> you'd have things like
>
> printk(.. irq %d .., irq_number(irqcookie) ..)
>
> which while not ugly isn't really all that clean either. And I guarantee
> that people would misuse that "irq_number(cookie)" exactly in the same
> ways they'd misuse "irq" (ie not very much).
Sparc32 had this and it was very ugly. However if you don't pass in the
IRQ then people will store the irq value privately and things like
request_irq can deal with numeric interrupts and the like as before while
new interfaces for MSI can deal in MSI objects whatever they end up like.
Kill off the *use* of the int irq passed into functions as Jeff has
basically done and you can later replace it with a structure that contains
useful info, some private some not. For now all it has to do is happen to
be a masked int as you suggest.
Alan
--
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