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]
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ