linux-kernel - Re: [RFC][PATCH] genirq: support multiple interrupt priorities

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20070806104644.GA4815@linux-sh.org>
Date:	Mon, 6 Aug 2007 19:46:44 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH] genirq: support multiple interrupt priorities

On Mon, Aug 06, 2007 at 12:36:09PM +0200, Ingo Molnar wrote:
> * Paul Mundt <lethal@...ux-sh.org> wrote:
> > This is a simple patch for adding trivial interrupt priority support.
> > 
> > I've added a ->set_prio() to the irq_chip which is implemented 
> > effectively the same way as ->set_type(), it's an optional component 
> > for those that really care about it.
> 
> i have no fundamental objections but it would be nice to actually 
> prototype this by implementing real priority support in the hardware: 
> both the i8259A and the IO-APIC/local-apic has such IRQ prioritization 
> features.
> 
I would not have written the patch if I did not have hardware that
supported it. I suppose I can start with interfacing the x86 PICs if that
makes it easier to swallow, though ;-)

> > + * IRQF_PRIO_HIGH - Give IRQ a high priority
> > + * IRQF_PRIO_LOW - Give IRQ a low priority
> 
> this should be a numeric scale. (Preferably in the 1-99 range (the 
> hardware can then do a lower-resolution thing out of it), so that we can 
> directly map this to IRQ threads and SCHED_FIFO priorities in -rt.)
> 
I don't disagree with that, but that makes it a little hard to pass in a
priority at request_irq() time. These IRQF_PRIO_HIGH/LOW are only for
such usage, the intent is to have a numeric value that's more meaningful
to the underlying hardware passed on to set_irq_prio() otherwise.

In any event, there's no problem with doing that anyways, both
IRQF_PRIO_HIGH and IRQF_PRIO_LOW are substantially above the 1-99 range
that the mask can be tested for if the underlying controller isn't
interested in mapping the 1-99 range to its own view of priorities.
Presumably you want this numeric range also reflected in the irq_desc for
-rt? If so, I'll start hacking something up.
-
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/