On Monday 21 May 2007, Cornelia Huck wrote:
> IRQ numbers are evil :)
yes, but getting rid of them is an entirely different discussion.
I really think that in the first step, you should be able to
use its "external interrupts" with the same request_irq interface
as the other architectures.
Fundamentally, the s390 architecture has external interrupt numbers
as well, you're just using a different interface for registering them.
The ccw devices obviously have a better interface already, but
that doesn't help you here.
> It should be more like a
> void *vmchannel_device_handle;
> which could be different things depending on what we want the
> vmchannel_device to be a child of (it could be an IRQ number for
> PCI devices, or something like subchannel_id if we wanted to
> support channel devices).
No, the driver needs to know how to get at the interrupt without
caring about the bus implementation, that's why you either need
to have a callback function set by the driver (like s390 CCW
or USB have it), or visible interrupt number (like everyone does).
There is no need for a pointer back to a vmchannel_device_handle,
all information needed by the bus layer can simply be in a
subclass derived from the vmchannel_device, e.g.
struct vmchannel_pci {
struct pci_device *parent; /* shortcut, same as
to_pci_dev(&this.vmdev.dev.parent) */
unsigned long signal_ioport; /* for interrupt generation */
struct vmchannel_device vmdev;
};
You would allocate this structure in the pci_driver that registers
the vmchannel_device.
Arnd <><
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
