|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [PATCH] pc: Clean up PIC-to-APIC IRQ path |
Date: | Sun, 04 Sep 2011 08:41:36 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 |
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.
The PCI bus *is* the I/O APIC for all intents and purposes. Being able to ask the i440fx for the interrupt corresponding to a device is a very simple task that involves no generic code. That's more than enough to support device assignment.
Why overcomplicate things when the problem can be solved robustly with most likely a 10 line function?
Regards, Anthony Liguori
Jan
[Prev in Thread] | Current Thread | [Next in Thread] |