Re: Ideas for abstracting driver IO from bus implementation?

Alan Cox (alan@lxorguk.ukuu.org.uk)
Thu, 18 Mar 1999 14:14:54 +0000 (GMT)


> By 'It' I assume you mean the device, not the I2O controller. I take it that
> the I2O controller shares IRQ/ioport/etc space with the CPU, and so a device
> at, say, a particular ioport for one will be visible at that same ioport for
> the other.

The I2O controller shares some busses with the CPU but not all. When it
reports what it has you get a report that seperates devices only it can see
from those you (the cpu) can directly see

> Out of interest, does this mean IRQs can be routed to an I2O controller
> instead of the CPU?

I'm not actually sure. I would assume so. Certainly I can't see how else
the I2O controller would be doing its work

> Does the I2O controller actually change the settings on the card itself, or
> does the O/S have to do that?

The OS does it. Currently you end up basically restarting the I2O
controller if you do this. For 2.0 you end up saying "excuse me please
rescan your busses"

> Can the I2O controller handle other things than PCI cards? How about things
> like SCSI devices that are hidden behind interface devices?

The CPU->I2O controller interface is defined right now for PCI. The I2O
controller can itself control anything the hardware allows it to on the
busses. Indeed I2O would work over ISA 8) it would just suck a lot that way.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/