On Sun, Sep 04, 2011 at 08:57:31AM -0500, Anthony Liguori wrote: > On 09/04/2011 08:49 AM, Jan Kiszka wrote: > > On 2011-09-04 15:41, Anthony Liguori wrote: > >> On 09/04/2011 08:36 AM, Jan Kiszka wrote: > >>> On 2011-09-04 15:32, Anthony Liguori wrote: > >>>> I prefer to not think of IRQs as special things. They're just single > >>>> bits of information that flow through the device model. Having a higher > >>>> level representation that understands something like paths seems wrong > >>>> to me. > >>>> > >>>> I'd prefer to treat things like device assignment as a hack. You just > >>>> need code that can walk the device tree to figure out the path (which is > >>>> not generic code, it's very machine specific). Then you tell the kernel > >>>> the resolution of the path and are otherwise completely oblivious in > >>>> userspace. > >>> > >>> See it as you like, but we need the support, not only for device > >>> assigment. And I do not see any gain it hacking this instead of > >>> designing it. > >> > >> You can design a hack but it's still a hack. > >> > >> Device state belongs in devices. Trying to extract device state > >> (interrupt routing paths) and externalizing it is by definition a hack. > >> > >> Having some sort of global interrupt routing table is just going to add > >> a layer of complexity for very little obvious gain. > > > > It's not yet decided how the problem is solved. A global interrupt > > matrix is just one proposal, another option is to extend the pin model > > in a way that supports routing change notifiers and backward polling. > > If that's all you need, then you really just want notification on socket > changes. Backwards polling can be achieved by just adding state to the > Pin (which I full heartedly support).
I'm not a fan of this backwards thing, but seeing the options available, it might be the simplest way forward. I agree that the global interrupt manager sounds like overkill... Cheers
