lkml.org 
[lkml]   [2008]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [git patch] free_irq() fixes


    On Thu, 24 Apr 2008, Jeff Garzik wrote:
    >
    > However, it does not follow that an int is what _must_ be passed around. We
    > already have design patterns like
    >
    > cookie_pointer = ioremap(raw bus resource)
    >
    > Not that I am the one pushing for that, just noting.

    I do agree that we could use something more type-safe.

    So a "pointer" to a structure that doesn't actually exist would be fine
    and would give us some C type checking.

    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).

    Quite frankly, I'd much prefer a

    typedef int __bitwise irq_t;

    and then we can use sparse to do this testing, without breaking any
    existing use at all (because it will still be an "int" to gcc, but sparse
    will make "irq_t" a type of its own and make sure that people pass it
    around as such and not do arithmetic ops on it etc).

    > > EVERYTHING else would be architecture-specific. And that is exactly what we
    > > do not want. EVER.
    >
    > Not true -- you have metadata/OOB data like MSI messages, where you are passed
    > a value from the PCI hardware in the PCI message, not just an "interrupt
    > asserted" condition. Or s/value/values/ if you enable PCI MSI's multiple
    > message support.

    The point is, MSI *is* architecture-specific. In fact, it's even
    motherboard-specific, in that you are going to have (for the forseeable
    future) drivers that have to work with or witgout MSI even on the same
    architecture.

    Linus


    \
     
     \ /
      Last update: 2008-04-24 17:59    [W:4.244 / U:1.200 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site