*Shiver* Looks like fun...
> It uses motherboard resources.
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.
Out of interest, does this mean IRQs can be routed to an I2O controller
instead of the CPU?
> You can also reconfigure those motherboard resources, but you have to beat
> the I2O controller around the head to do it. I2O 2.0 is supposed to clean
> that up and handle I2O management of hot plug PCI devices
This is, I think, the primary objective of my 'interface' abstraction. The
configuration manager tells the interface to reconfigure the resources a
device uses. The interface can say no, or it can use what ever protocol(s) are
necessary to actually change the settings on the device.
Does the I2O controller actually change the settings on the card itself, or
does the O/S have to do that?
Can the I2O controller handle other things than PCI cards? How about things
like SCSI devices that are hidden behind interface devices?
> I was anticipating that you would need to have an "owner" for each device,
> and that owner which now happens to always been the CPU might change. Then
> you'd call the owners methods for reassignment notification.
Hmmm... Having set out the questions above, I think I see where you're
going... It sounds like a derivative of the 'interface' abstraction I use, but
not quite.
Firstly, you'd have an abstraction ('owner') that says who makes the changes
to a device's configuration and who can command/access it.
Secondly, you'd have an abstraction ('interface') that says how changes are
made to a device's configuration by the CPU owner and how its registers are
accessed (eg: PCI, PnP, PnP-BIOS, PCMCIA, MCA).
So, this is a simplified version of the abstractions I have in mind:
OWNER {
DEVICE*; /* device which this owner is */
reconfigure(); /* method to reconfigure a device */
send_command(); /* MAYBE - send some sort of command */
}
INTERFACE {
read_config(); /* read device's current configuration */
set_config(); /* set device's current configuration */
possible_config(); /* find out device's possible configurations */
read_registers(); /* read a device's control registers */
set_registers(); /* set a device's control registers */
}
DRIVER {
control_device(); /* control a device */
device_configured(); /* notification of device reconfiguration */
}
BUS {
DEVICE*; /* device acting as bridge to this bus */
}
DEVICE {
OWNER*; /* owner of this device */
INTERFACE*; /* protocol by which this device changed */
BUS*; /* bus on which this device resides */
DRIVER*; /* driver controlling this bus */
CONFIG*; /* current configuration of this device */
}
David Howells
-
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/