2012/3/3 Zhi Yong Wu <zwu.ker...@gmail.com>: > thanks a lot for your help, they are very in theory.:). actually these > concepts all exist in QEMU. I would like to know how they work > together.
It's a mess. qemu_irq is the most fundamental data type we use to model a general 'pin' or 'signal' line; despite the name it can be used for other things besides interrupt lines, like general purpose I/O. This is used by basically all devices. The base class Device for all devices implemented using the QEMU Object Model provides a number of qdev_* functions for registering and manipulating input and output I/O lines, eg qdev_get_gpio_in and qdev_connect_gpio_out. These are written in terms of the basic qemu_irq type. Despite the 'gpio' name, you can use these for interrupt lines if you want. The SysBus class (used for a lot of devices which are really just trying to provide memory-mapped I/O and some interrupt or signal lines) also provides an abstraction of qemu_irq (functions sysbus_connect_irq(), sysbus_init_irq(), etc). Again, there's no reason you can't use these for other purposes than interrupts, although since every SysBus device is also a Device, mostly by convention the sysbus abstraction is used for the real outbound interrupt lines and the Device gpio abstraction for everything else. My opinion is that we should clean this up as part of properly converting to the new object model. In particular SysBus should just disappear and all Devices should be able to export named input and output signals, which can be used for interrupts or general I/O or whatever. Unfortunately we're probably stuck with the incredibly badly named 'qemu_irq' type for the rest of eternity... -- PMM