On Sun, Sep 4, 2011 at 2:43 PM, Anthony Liguori <anth...@codemonkey.ws> wrote: > On 09/04/2011 09:12 AM, Avi Kivity wrote: >> >> On 09/04/2011 04:41 PM, Anthony Liguori wrote: >>>> >>>> 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. >> >> Pet peeve - saying something is "by definition" a hack is just rhetoric >> unless the definition of device state is "something that cannot be >> extracted and externalized". Let's avoid this. > > Likewise, I would prefer to avoid stating that something is a hard > requirement in the absence of concrete use-cases. > > I do think the definition of device state is more or less something that is > opaque and owned by the device. The more we externalize the device state, > the more we have to deal with compatibility (even if it's just internal > compatibility). This makes modularity hard because there's too many things > with complex dependencies. > >> In fact it's exactly what we do with the memory API. Memory routing is >> part of device state, yet we expose it to the memory API and let it do >> its thing instead of going through the hierarchy on every single memory >> access. > > Yes, and the memory API is complicated and invasive :-) But it's worth it > at the end of the day (although I think it could be simplified at the > expensive of not allowing as much flattening). > >> Whether it's worthwhile to do this for interrupts as well depends on how >> common the situation is and what we gain from it. We can only do this if >> the routing is semi-static (depends only on other state but not the >> actual interrupt) - probably the only exception to this is the "least >> priority" mode which means the last leg cannot be computed statically. >> >> I agree the gain is low if we limit ourselves to 440fx, but if we add >> interrupt remapping it becomes considerably more complicated to do this >> backward path computation. > > If we start with a simple interface that works for the i440fx and then > expand it as we support more layers, I think we'll be okay. > > What I'm concerned about is an attempt to globally track IRQ routing. I can > imagine constructing a board where you have two simple devices that have > level triggered interrupts and wanting to tie them to a single input pin. A > simple OR gate would be sufficient to do this. Having to make an OR gate an > IRQ router seems like far too much complexity to me.
For the simple OR gate this is a downside of course, but I don't see a way to avoid it, same with the memory API or other APIs that need to cater for wide variety of needs. > I think we need to strive to keep simple things simple. If the APIs need only minor changes, the changes to the devices would not be so big. At this point I think your router API would only need the change callback to support the matrix and Pin should be compatible. > Regards, > > Anthony Liguori > >
