Re: [RFC] killing the NR_IRQS arrays.

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.

I have to admit I still don't really understand how this works
at all. Can a driver that uses msi-x have different handlers
for each of those interrupts registered simultaneously?

Yes. It doesn't have to, though.

I would expect that instead there should be only one 'struct irq'
for the device, with the handler getting a 12 bit number argument.

Why? The device really generates many different interrupts,
why hide this fact.

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

I was wondering about that. Do you only mean /proc/interrupts or
are there other user interfaces we need to worry about?

There's the IRQ affinity stuff too.

For /proc/interrupts, what could break if we have interrupt numbers
only local to each controller and potentially duplicate numbers
in the list? It's good to be paranoid about changes to proc files,
but I can definitely see value in having meaningful interrupt
numbers in there instead of making up a more or less random mapping
to a flat number space.

Duplicate all this stuff into /sys in a sane format (*) and
wait until userland catches up, then throw away the /proc
interfaces. It'll take a while, and until that day you will
have to keep *some* interrupt number <-> interrupt bijection.
Userland tools that think they know what interrupt number
should be what are dead already.

(*) i.e., exposing the interrupt tree as a tree, cascaded
controllers and all.


Segher

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [PATCH 0/5] forcedeth: several proposed updates for testing
    ... The queueing model in forcedeth seemed to be not that robust and i think a single queueing model should be adopted instead of this tunable. ... and separate interrupt vectors for RX and TX. ... so, NVIDIA's MSI-X implementation, our generic MSI-X support, or "Known bugs" may be a factor here. ... Testing welcome;-) Though these patches are raw and "hot off the presses", so unrelated bugs are practically a certainty. ...
    (Linux-Kernel)
  • [PATCH 2.6.20.3] Flush writes to MSI-X table
    ... Because both MSI-X interrupt messages and MSI-X table writes are posted, ... static void msi_set_mask_bit(unsigned int irq, ...
    (Linux-Kernel)
  • [PATCH 2.6.21-rc4] Flush writes to MSI-X table
    ... Because both MSI-X interrupt messages and MSI-X table writes are posted, ... static void msi_set_mask_bit(unsigned int irq, ...
    (Linux-Kernel)
  • [PATCH 2.6.20.4]
    ... This patch fixes a kernel bug which is triggered when using the ... Because both MSI-X interrupt messages and MSI-X table writes are posted, ... static void msi_set_mask_bit(unsigned int irq, ...
    (Linux-Kernel)
  • [PATCH 2.6.21-rc5] Flush MSI-X table writes (rev 3)
    ... This patch fixes a kernel bug which is triggered when using the ... Because both MSI-X interrupt messages and MSI-X table writes are posted, ... static void msi_set_mask_bit(unsigned int irq, ...
    (Linux-Kernel)