On Tue, 2010-10-26 at 13:20 +0200, Markus Armbruster wrote: > >> How to tell whether it's primary or secondary? Primary uses I/O ports > >> 0x1f0..0x1ff,0x3f0..0x3ff and IRQ 14. IRQ could be easier to check, > >> because it should be right in ISADevice member isairq[0]. > >> Alternatively, upcast to ISAIDEState and check members iobase or isairq. > > Again idebus_dev_path() should not care about what device IDEBus resides on. > > We really need to define what qbus's get_dev_path() callback is supposed > to do before we continue. Alex, you created it. What's your take on > its semantics?
Perhaps going into too much detail, but the idea of get_dev_path() is that it's a recursive call up the device try, where each level adds a string to come up with a unique description. We currently only have this of PCI because it's device path is obvious, while others are not, particularly ISA. To start, I'd think IDE could easily implement a get_dev_path(), where the IDE qbus calls up to it's parent bus, then appends IDE channel and slot. So for a PCI IDE controller, we get something like PCI:0000:00:03.0/piix3-IDE0.master (change this to match qdev info strings, I'm just making it up here). An ISA IDE controller is harder since ISA doesn't have a bus enumeration mechanism. IIRC, there we some suggestions to use ioports and/or irqs to define a path on ISA, but not all ISA qdev devices expose these. So perhaps we'd want something like isa.irq14/piix3-IDE0.master. Doing ISA correctly probably means standardizing some portion of the qdev info for all the ISA devices. Thanks, Alex
