[lkml]   [2007]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-02-28 14:05    [W:0.449 / U:7.732 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site